Re: Prefetch the next tuple's memory during seqscans - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Prefetch the next tuple's memory during seqscans
Date
Msg-id 20221102030043.3zsmfyxnvhgprgo2@awork3.anarazel.de
Whole thread Raw
In response to Prefetch the next tuple's memory during seqscans  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Prefetch the next tuple's memory during seqscans
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL cursors should get generated portal names by default
Next
From: Andy Fan
Date:
Subject: A new strategy for pull-up correlated ANY_SUBLINK