Re: Add index scan progress to pg_stat_progress_vacuum

Поиск
Список
Период
Сортировка
От Imseih (AWS), Sami
Тема Re: Add index scan progress to pg_stat_progress_vacuum
Дата
Msg-id 7C22F915-5BB8-4729-8FF1-98B774CD6C85@amazon.com
обсуждение исходный текст
Ответ на Re: Add index scan progress to pg_stat_progress_vacuum  (Andres Freund <andres@anarazel.de>)
Ответы Re: Add index scan progress to pg_stat_progress_vacuum
Список pgsql-hackers
>    I don't think any of these progress callbacks should be done while pinning a
>    buffer and ...

Good point.

>    I also don't understand why info->parallel_progress_callback exists? It's only
>    set to parallel_vacuum_progress_report(). Why make this stuff more expensive
>    than it has to already be?

Agree. Modified the patch to avoid the callback .

>    So each of the places that call this need to make an additional external
>    function call for each page, just to find that there's nothing to do or to
>    make yet another indirect function call. This should probably a static inline
>    function.

Even better to just remove a function call altogether.

>    This is called, for every single page, just to read the number of indexes
>    completed by workers? A number that barely ever changes?

I will take the initial suggestion by Sawada-san to update the progress
every 1GB of blocks scanned. 

Also, It sems to me that we don't need to track progress in brin indexes,
Since it is rare, if ever, this type of index will go through very heavy
block scans. In fact, I noticed the vacuum AMs for brin don't invoke the
vacuum_delay_point at all.

The attached patch addresses the feedback.


Regards,

Sami Imseih
Amazon Web Services (AWS) 



Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans
Следующее
От: Tom Lane
Дата:
Сообщение: Making Bitmapsets be valid Nodes