From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Rahila Syed <rahilasyed90(at)gmail(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, pokurev(at)pm(dot)nttdata(dot)co(dot)jp, bannos(at)nttdata(dot)co(dot)jp |
Subject: | Re: [PROPOSAL] VACUUM Progress Checker. |
Date: | 2016-03-14 11:04:48 |
Message-ID: | CA+HiwqGQXOg3iC6SJB9a9rxTX1ZB=stTWGmjP3UJdXCar_JwHA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Thanks for taking a look at the patch.
On Mon, Mar 14, 2016 at 6:55 PM, Rahila Syed <rahilasyed90(at)gmail(dot)com> wrote:
> Hello,
>
> While I am still looking at this WIP patch, I had one suggestion.
>
> Instead of making changes in the index AM API can we have a call to update
> the shared state using pgstat_progress* API
>
> directly from specific index level code?
>
> Like pgstat_count_index_scan(rel) call from _bt_first does. Though this
> function basically updates local structures and sends the count to stat
> collector via messages we can have a function which will instead modify the
> shared state using the progress API committed recently.
I chose the callback approach because we need to count the index
blocks within the context of a given vacuum run. For example, as
proposed, progress_callback_state (in this case, a pointer to the
LVRelStats struct for a given vacuum run) keeps the block count for a
given index vacuum run. It is reset when next index vacuuming round
starts. Also, remember that the count is across all indexes.
If we call pgstat_progress API directly from within AM, what I just
described above seems difficult to achieve modularly. But maybe, I'm
missing something.
Aside from whether we should use one of the above two methods, I think
we also have to figure out, for each AM, how to count correctly
considering non-linearity (tree traversal, recursion and such) of most
AMs' vacuum scans.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Shulgin | 2016-03-14 11:43:40 | Re: Sanity checking for ./configure options? |
Previous Message | Shulgin, Oleksandr | 2016-03-14 10:58:32 | Re: Add schema-qualified relnames in constraint error messages. |