On 2016/01/29 21:02, Rahila Syed wrote: >> 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. > > Apart from these, as suggested in [1] , finer grained reporting from index > vacuuming phase can provide better insight. Currently we report number of > blocks processed once at the end of vacuuming of each index. > IIUC, what was suggested in [1] was instrumenting lazy_tid_reaped with a > counter to count number of index tuples processed so far as lazy_tid_reaped > is called for every index tuple to see if it matches any of the dead tuple > tids.
Agreed. Although, as Robert already suggested, I too would vote for counting pages, not tuples. I think there was an independent patch doing something of that sort somewhere upthread. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
