Re: [PROPOSAL] VACUUM Progress Checker.
От | Amit Langote |
---|---|
Тема | Re: [PROPOSAL] VACUUM Progress Checker. |
Дата | |
Msg-id | 56AEB4BA.2030603@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] VACUUM Progress Checker. (Rahila Syed <rahilasyed90@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: