On Tue, Feb 7, 2023 at 11:24 PM Rinat Shigapov <rinatshiga...@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: https://www.postgresql.org/message-id/flat/CAEepm%3D2GK3FVdnt5V3d%2Bh9njWipCv_fNL%3DwjxyUhzsF%3D0PcbNg%40mail.gmail.com 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.
