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 по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Template for commit messages
Следующее
От: Kouhei Kaigai
Дата:
Сообщение: Way to check whether a particular block is on the shared_buffer?