On 2016/01/28 23:53, Robert Haas wrote: > On Thu, Jan 28, 2016 at 8:41 AM, Amit Langote <amitlangot...@gmail.com> wrote: >> Or keep scanned_heap_pages as is and add a skipped_pages (or >> skipped_heap_pages). I guess the latter would be updated not only for >> all visible skipped pages but also pin skipped pages. That is, >> updating its counter right after vacrelstats->pinskipped_pages++ which >> there are a couple of instances of. Likewise a good (and only?) time >> to update the former's counter would be right after >> vacrelstats->scanned_pages++. Although, I see at least one place where >> both are incremented so maybe I'm not entirely correct about the last >> two sentences. > > So I've spent a fair amount of time debugging really-long-running > VACUUM processes with customers, and generally what I really want to > know is: > >>>> What block number are we at? <<< > > Because, if I know that, and I can see how fast that's increasing, > then I can estimate whether the VACUUM is going to end in a reasonable > period of time or not. So my preference is to not bother breaking out > skipped pages, but just report the block number and call it good. I > will defer to a strong consensus on something else, but reporting the > block number has the advantage of being dead simple and, in my > experience, that would answer the question that I typically have.
Okay, I agree that reporting just the current blkno is simple and good enough. How about numbers of what we're going to report as the "Vacuuming Index and Heap" phase? I guess we can still keep the scanned_index_pages and index_scan_count. So we have: +CREATE VIEW pg_stat_vacuum_progress AS + SELECT + S.pid, + S.relid, + S.phase, + S.total_heap_blks, + S.current_heap_blkno, + S.total_index_pages, + S.scanned_index_pages, + S.index_scan_count + S.percent_complete, + FROM pg_stat_get_vacuum_progress() AS S; I guess it won't remain pg_stat_get_"vacuum"_progress(), though. Thanks, Amit -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers