Re: [PROPOSAL] VACUUM Progress Checker. - Mailing list pgsql-hackers

From Rahila Syed
Subject Re: [PROPOSAL] VACUUM Progress Checker.
Date
Msg-id CAH2L28sU1w0SGw9a9y6J4+sBLzUrz8KpL+Fi2wLFZ7zuFV_wqQ@mail.gmail.com
Whole thread Raw
In response to Re: [PROPOSAL] VACUUM Progress Checker.  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: [PROPOSAL] VACUUM Progress Checker.  (Robert Haas <robertmhaas@gmail.com>)
Re: [PROPOSAL] VACUUM Progress Checker.  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
>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.

So additional parameters for each index can be,
scanned_index_tuples
total_index_tuples (from pg_class.reltuples entry)

Thank you,
Rahila Syed


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Sequence Access Method WIP
Next
From: Mithun Cy
Date:
Subject: Re: Using quicksort for every external sort run