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
|
Список | 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 по дате отправления: