| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, 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>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Subject: | Re: index prefetching |
| Date: | 2025-12-17 19:53:48 |
| Message-ID: | CAH2-Wz=imnxHceg9cgprLuDXKKzqqEo4SaUOALgko1qWi=VULw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 17, 2025 at 2:30 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Note that due to the tuple size and fillfactor in Konstantin's workload, there
> will be one tuple per page... That should allow for some prefetching.
I don't see how, unless he also set leaf fillfactor very low (though
probably not even then, with LIMIT 1, since you still get a few index
tuples on each leaf page).
As Tomas points out, this particularly heuristic probably has some
problems. I'm not claiming that this is the ideal behavior. Just that
it would seem to make it almost impossible for prefetching to ever
show benefits, with a workload such as this (in particular with LIMIT
1 it seems quite impossible).
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2025-12-17 19:54:04 | Re: index prefetching |
| Previous Message | Noah Misch | 2025-12-17 19:51:33 | Re: pg_dump crash due to incomplete ordering of DO_SUBSCRIPTION_REL objects |