Re: Prefetch the next tuple's memory during seqscans
| От | David Rowley |
|---|---|
| Тема | Re: Prefetch the next tuple's memory during seqscans |
| Дата | |
| Msg-id | CAApHDvrxLgFpm2-bC8ZfPRwVPOWQ=Eciu_4Uv3cBpSzDkg3V_g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Prefetch the next tuple's memory during seqscans (sirisha chamarthi <sirichamarthi22@gmail.com>) |
| Ответы |
Re: Prefetch the next tuple's memory during seqscans
|
| Список | 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 по дате отправления: