| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>, 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: | 2026-03-31 17:39:30 |
| Message-ID: | CAH2-WzkFRoTjD9T8ykYDzOMxzGiWFqcAkbK8B=HjfpoMdM4E8A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 27, 2026 at 8:35 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> Attached is v18, which addresses the tricky issues I skipped in v17.
v19 is attached. It contains a few notable improvements over v18:
* The first commit (the one that simply moves code into the new
heapam_indexscan.c file) now moves heap_hot_search_buffer over there
as well.
Andres suggested this at one point, and I believe it wins us a small
but significant performance benefit.
> * The "Add UnlockBufferGetLSN utility function" commit now uses an
> atomic operation (in the common case where it actually drops the index
> page's pin), just like UnlockReleaseBuffer itself following Andres'
> commit f39cb8c011062d65e146c1e9d1aae221e96d8320 from today.
* v19 removes the "Add UnlockBufferGetLSN utility function" patch entirely.
Following Andres' commit f39cb8c0, this no longer seemed to help
performance (compared to just calling BufferGetLSNAtomic and
UnlockReleaseBuffer directly), so I removed it.
> I believe I have now acted on all of Andres' feedback, with one minor
> exception: Andres disliked how we use 'if (scan->xs_heapfetch)' to
> determine whether to use the scan's batch cache (we don't want to use
> it at all if the scan is ending). I just ran out of steam, so this
> version doesn't address the problem.
* v19 fixes this by adding a new helper function. This allows us to
pass down the required context (whether the scan is ending) to inform
the relevant batch recycling code whether it really should place its
caller's batch in the scan's cache (or whether it should just pfree it
right away).
As in previous versions, I'm including several extra read stream
patches to address various problems in that area. These problems, tied
to how index prefetching stresses the read stream that are new and not
encountered by existing read stream users. Andres wrote all of these
patches. Those aspects of the patch should be discussed on a new
thread dedicated to index prefetching-related read stream
enhancements: https://postgr.es/m/f3xxfrkafjxpyqxywcxricxgyizjirfceychyxsgn7bwjp5eda@kwbduhy7tfmu
(Though I'm also carrying some extra bug fix patches here, not
included on that other thread, to address preexisting read stream
bugs, albeit bugs highly unlikely to affect current read stream
users.)
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-03-31 17:41:18 | Re: EXPLAIN: showing ReadStream / prefetch stats |
| Previous Message | Srinath Reddy Sadipiralla | 2026-03-31 17:37:17 | Re: Adding REPACK [concurrently] |