Re: [PROPOSAL] VACUUM Progress Checker.
От | Amit Langote |
---|---|
Тема | Re: [PROPOSAL] VACUUM Progress Checker. |
Дата | |
Msg-id | CA+HiwqGQXOg3iC6SJB9a9rxTX1ZB=stTWGmjP3UJdXCar_JwHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] VACUUM Progress Checker. (Rahila Syed <rahilasyed90@gmail.com>) |
Список | pgsql-hackers |
Hi, Thanks for taking a look at the patch. On Mon, Mar 14, 2016 at 6:55 PM, Rahila Syed <rahilasyed90@gmail.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
В списке pgsql-hackers по дате отправления: