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

From David Rowley
Subject Re: Prefetch the next tuple's memory during seqscans
Date
Msg-id CAApHDvrxLgFpm2-bC8ZfPRwVPOWQ=Eciu_4Uv3cBpSzDkg3V_g@mail.gmail.com
Whole thread Raw
In response to Re: Prefetch the next tuple's memory during seqscans  (sirisha chamarthi <sirichamarthi22@gmail.com>)
Responses Re: Prefetch the next tuple's memory during seqscans
List pgsql-hackers
On Wed, 23 Nov 2022 at 20:29, sirisha chamarthi
<sirichamarthi22@gmail.com> wrote:
> I ran your test1 exactly like your setup except the row count is 3000000 (with 13275 blocks). Shared_buffers is 128MB
andthe hardware configuration details at the bottom of the mail. It appears Master + 0001 + 0005 regressed compared to
masterslightly . 

Thank you for running these tests.

Can you share if the plans used for these queries was a parallel plan?
I had set max_parallel_workers_per_gather to 0 to remove the
additional variability from parallel query.

Also, 13275 blocks is 104MBs, does EXPLAIN (ANALYZE, BUFFERS) indicate
that all pages were in shared buffers? I used pg_prewarm() to ensure
they were so that the runs were consistent.

David



pgsql-hackers by date:

Previous
From: sirisha chamarthi
Date:
Subject: Re: Prefetch the next tuple's memory during seqscans
Next
From: Peter Eisentraut
Date:
Subject: drop postmaster symlink