Thomas, thank you for the details! Have you kept the branch that you used to generate the patch? Which commit should the patch apply to?
With kindest regards, Rinat Shigapov вт, 7 февр. 2023 г. в 17:11, Thomas Munro <thomas.mu...@gmail.com>: > 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. >
