From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Chris Travers <chris(dot)travers(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: POC: Lock updated tuples in tuple_update() and tuple_delete() |
Date: | 2023-03-31 13:57:41 |
Message-ID: | CAPpHfduoYQ6zLFB2ajWkr61RZKEpaQVO3tQVCd-8sXkNSs_Ajg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 29, 2023 at 8:34 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> 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.
Sorry, previous patches don't even compile. The fixed version is attached.
I'm going to post significantly revised patchset soon.
------
Regards,
Alexander Korotkov
Attachment | Content-Type | Size |
---|---|---|
0001-Improve-lazy-tuple-slot-v2.patch | application/octet-stream | 4.9 KB |
0002-Revise-changes-for-tuple_update-and-tuple_delete-v2.patch | application/octet-stream | 55.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2023-03-31 14:00:00 | Re: regression coverage gaps for gist and hash indexes |
Previous Message | Melanie Plageman | 2023-03-31 13:52:08 | Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode |