On 2016/01/28 23:53, Robert Haas wrote:
> On Thu, Jan 28, 2016 at 8:41 AM, Amit Langote <amitlangote09@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