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

Andres,

On Mon, Mar 27, 2023 at 1:49 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> On Fri, Mar 24, 2023 at 3:39 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2023-03-23 23:24:19 +0300, Alexander Korotkov wrote:
> > > On Thu, Mar 23, 2023 at 8:06 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > > I seriously doubt that solving this at the tuple locking level is the right
> > > > thing. If we want to avoid refetching tuples, why don't we add a parameter to
> > > > delete/update to generally put the old tuple version into a slot, not just as
> > > > an optimization for a subsequent lock_tuple()? Then we could remove all
> > > > refetching tuples for triggers. It'd also provide the basis for adding support
> > > > for referencing the OLD version in RETURNING, which'd be quite powerful.
>
> After some thoughts, I think I like idea of fetching old tuple version
> in update/delete. Everything that evades extra tuple fetching and do
> more of related work in a single table AM call, makes table AM API
> more flexible.
>
> I'm working on patch implementing this. I'm going to post it later today.

Here is the patchset. I'm continue to work on comments and refactoring.

My quick question is why do we need ri_TrigOldSlot for triggers?
Can't we just pass the old tuple for after row trigger in
ri_oldTupleSlot?

Also, I wonder if we really need a LazyTupleSlot. It allows to evade
extra tuple slot allocation. But as I get in the end the tuple slot
allocation is just a single palloc. I bet the effect would be
invisible in the benchmarks.

------
Regards,
Alexander Korotkov