Re: POC: Lock updated tuples in tuple_update() and tuple_delete()
От | Alexander Korotkov |
---|---|
Тема | Re: POC: Lock updated tuples in tuple_update() and tuple_delete() |
Дата | |
Msg-id | CAPpHfdun_qexYDud7q=eBxHF7Xsddq681i_k_xu4RyqCzPd8WQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: POC: Lock updated tuples in tuple_update() and tuple_delete() (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: POC: Lock updated tuples in tuple_update() and tuple_delete()
|
Список | pgsql-hackers |
Hi! On Fri, Mar 24, 2023 at 3:39 AM Andres Freund <andres@anarazel.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@anarazel.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. ------ Regards, Alexander Korotkov
В списке pgsql-hackers по дате отправления: