Re: index prefetching - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: index prefetching
Date
Msg-id CAH2-Wz=1hRnAitGNBmyTUzcbqoqUGSJFhoEPqDB6L1S9O=gJQQ@mail.gmail.com
Whole thread Raw
In response to Re: index prefetching  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Sat, Jul 12, 2025 at 7:50 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Why wouldn't we want to relieve all AMs of that responsibility?
> Leaving it up to index AMs has resulted in subtle bugs [2][3], and
> AFAICT has no redeeming quality. If affected index AMs were *forced*
> to do *exactly* the same thing as each other (not just *oblidged* to
> do *almost* the same thing), it would make life easier for everybody.
>
> [1] https://www.postgresql.org/docs/current/index-locking.html
> [2] https://commitfest.postgresql.org/patch/5721/
> [3] https://commitfest.postgresql.org/patch/5542/

The kill_prior_tuple code that GiST uses to set LP_DEAD bits is also
buggy, as is the equivalent code used by hash indexes:

https://www.postgresql.org/message-id/CAH2-Wz%3D3eeujcHi3P_r%2BL8n-vDjdue9yGa%2Bytb95zh--S9kWfA%40mail.gmail.com

This seems like another case where a non-nbtree index AM copied
something from nbtree but didn't quite get the details right. Most
likely because the underlying principles weren't really understood
(even though they are in fact totally independent of index
AM/amgettuple implementation details).

BTW, neither gistkillitems() nor _hash_kill_items() have any test coverage.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Issues with hash and GiST LP_DEAD setting for kill_prior_tuple
Next
From: Álvaro Herrera
Date:
Subject: refactor backend type lists