Re: Confine vacuum skip logic to lazy_scan_skip

Поиск
Список
Период
Сортировка
От Nazir Bilal Yavuz
Тема Re: Confine vacuum skip logic to lazy_scan_skip
Дата
Msg-id CAN55FZ00tfPb9GxtL-qe8OgpjXOFj9HBGCibGO10DGytxs0GTw@mail.gmail.com
обсуждение исходный текст
Ответ на Confine vacuum skip logic to lazy_scan_skip  (Melanie Plageman <melanieplageman@gmail.com>)
Ответы Re: Confine vacuum skip logic to lazy_scan_skip  (Melanie Plageman <melanieplageman@gmail.com>)
Список pgsql-hackers
Hi,

On Fri, 5 Jan 2024 at 02:25, Jim Nasby <jim.nasby@gmail.com> wrote:
>
> On 1/4/24 2:23 PM, Andres Freund wrote:
>
> On 2024-01-02 12:36:18 -0500, Melanie Plageman wrote:
>
> Subject: [PATCH v2 1/6] lazy_scan_skip remove unnecessary local var rel_pages
> Subject: [PATCH v2 2/6] lazy_scan_skip remove unneeded local var
>  nskippable_blocks
>
> I think these may lead to worse code - the compiler has to reload
> vacrel->rel_pages/next_unskippable_block for every loop iteration, because it
> can't guarantee that they're not changed within one of the external functions
> called in the loop body.
>
> Admittedly I'm not up to speed on recent vacuum changes, but I have to wonder if the concept of skipping should go
awayin the context of vector IO? Instead of thinking about "we can skip this range of blocks", why not maintain a list
of"here's the next X number of blocks that we need to vacuum"? 

Sorry if I misunderstood. AFAIU, with the help of the vectored IO;
"the next X number of blocks that need to be vacuumed" will be
prefetched by calculating the unskippable blocks ( using the
lazy_scan_skip() function ) and the X will be determined by Postgres
itself. Do you have something different in your mind?

--
Regards,
Nazir Bilal Yavuz
Microsoft



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

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: generic plans and "initial" pruning
Следующее
От: John Naylor
Дата:
Сообщение: Re: Change GUC hashtable to use simplehash?