From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Georgios <gkokolatos(at)protonmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Subject: | Re: index prefetching |
Date: | 2025-08-15 17:09:24 |
Message-ID: | 2q3m2vgaz3qih7qfjwqnx2e6d3aslyisvsslahioipb75vgl5i@3zmvjcww7sy5 |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Glad to see that the prototype does fix the issue for you.
On 2025-08-15 12:29:25 -0400, Peter Geoghegan wrote:
> FWIW, this development probably completely changes the results of many
> (all?) of your benchmark queries. My guess is that with Andres' patch,
> things will be better across the board. But in any case the numbers
> that you posted before now must now be considered
> obsolete/nonrepresentative. Since this is such a huge change.
I'd hope it doesn't improve all benchmark queries - if so the set of
benchmarks would IMO be too skewed towards cases that access the same heap
blocks multiple times within the readahead distance. That's definitely an
important thing to measure, but it's surely not the only thing to care
about. For the index workloads the patch doesn't do anything about cases where
we don't up re-encountering a buffer that we already started IO for.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Burd, Greg | 2025-08-15 17:12:58 | Re: `pg_ctl init` crashes when run concurrently; semget(2) suspected |
Previous Message | Tom Lane | 2025-08-15 16:57:02 | Re: Making jsonb_agg() faster |