Re: POC: Lock updated tuples in tuple_update() and tuple_delete()

On Wed, Mar 8, 2023 at 4:22 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2023-03-07 04:45:32 +0300, Alexander Korotkov wrote:
> > The second patch now implements a concept of LazyTupleTableSlot, a slot
> > which gets allocated only when needed. Also, there is more minor
> > refactoring and more comments.
>
> This patch already is pretty big for what it actually improves. Introducing
> even infrastructure to get a not that big win, in a not particularly
> interesting, extreme, workload...

It's true that the win isn't dramatic. But can't agree that workload
isn't interesting. In my experience, high-contention over limited set
of row is something that frequently happen is production. I
personally took part in multiple investigations over such workloads.

> What is motivating this?

Right, the improvement this patch gives to heap is not the full
motivation. Another motivation is improvement it gives to TableAM
API. Our current API implies that the effort on locating the tuple by
tid is small. This is more or less true for heap, where we just need
to pin and lock the buffer. But imagine other TableAM
implementations, where locating a tuple is more expensive. Current
API insist that we do that twice in update attempt and lock. Doing
that in single call could give such TableAM's singification economy
(but even for heap it's something). I'm working on such TableAM: it's
OrioleDB which implements index-organized tables. And I know there
are other examples (for instance, zedstore), where TID lookup includes
some indirection.

------
Regards,
Alexander Korotkov