On Tue, Feb 7, 2023 at 11:24 PM Rinat Shigapov <rinatshigapov@gmail.com> wrote: > Does the current PostgreSQL release support B+ tree index predicate locks more granular then page-level locks?
No. I tried to follow some breadcrumbs left by Kevin and Dan that should allow unique index scans that find a match to skip the btree page lock, though, and p-lock just the heap tuple. If you like half-baked experimental code, see the v4-0002 patch in this thread, where I took some shortcuts (jamming stuff that should be in the planner down into the executor) for a proof-of-concept:
With that approach, if it *doesn't* find a match, then you're back to having to p-lock the whole index page to represent the "gap", so that you can conflict with anyone who tries to insert a matching value later. I believe the next-key approach would allow for finer grained gap-locks (haven't studied that myself), but that's a secondary problem; the primary problem (it seems to me) is getting rid of index locks completely in the (common?) case that you have a qualifying match.
