Re: Prefetch the next tuple's memory during seqscans

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Prefetch the next tuple's memory during seqscans
Дата
Msg-id 20221102030043.3zsmfyxnvhgprgo2@awork3.anarazel.de
обсуждение исходный текст
Ответ на Prefetch the next tuple's memory during seqscans  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Prefetch the next tuple's memory during seqscans  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi,

On 2022-10-31 16:52:52 +1300, David Rowley wrote:
> As part of the AIO work [1], Andres mentioned to me that he found that
> prefetching tuple memory during hot pruning showed significant wins.
> I'm not proposing anything to improve HOT pruning here

I did try and reproduce my old results, and it does look like we already get
most of the gains from prefetching via 18b87b201f7. I see gains from
prefetching before that patch, but see it hurt after. If I reverse the
iteration order from 18b87b201f7 prefetching helps again.


> but as a segue to get the prefetching infrastructure in so that there are
> fewer AIO patches, I'm proposing we prefetch the next tuple during sequence
> scans in while page mode.

> Time: 328.225 ms (avg ~7.7% faster)
> ...
> Time: 410.843 ms (avg ~22% faster)

That's a pretty impressive result.


I suspect that prefetching in heapgetpage() would provide gains as well, at
least for pages that aren't marked all-visible, pretty common in the real
world IME.

Greetings,

Andres Freund



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: PL/pgSQL cursors should get generated portal names by default
Следующее
От: Andy Fan
Дата:
Сообщение: A new strategy for pull-up correlated ANY_SUBLINK