Re: Too coarse predicate locks granularity for B+ tree indexes

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(dot)munro(at)gmail(dot)com>:

> On Tue, Feb 7, 2023 at 11:24 PM Rinat Shigapov <rinatshigapov(at)gmail(dot)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.
>