Re: ModifyTable overheads in generic plans - Mailing list pgsql-hackers

From Amit Langote
Subject Re: ModifyTable overheads in generic plans
Date
Msg-id CA+HiwqFhBX6f80qSz2OURYws0JzOUZQi-c9C3j4Rp0O5JGxPKA@mail.gmail.com
Whole thread Raw
In response to Re: ModifyTable overheads in generic plans  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Apr 8, 2021 at 1:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Langote <amitlangote09@gmail.com> writes:
> > Also, I think we should update the commentary around ri_projectNew a
> > bit to make it clear that noplace beside ExecGet{Insert|Update}Tuple
> > should be touching it and the associated slots.
>
> Hm.  I pushed your comment fixes in nodeModifyTable.c, but not this
> change, because it seemed to be more verbose and not really an
> improvement.  Why are these fields any more hands-off than any others?
> Besides which, there certainly is other code touching ri_oldTupleSlot.

Oops, that's right.

> Anyway, I've marked the CF entry closed, because I think this is about
> as far as we can get for v14.  I'm not averse to revisiting the
> RETURNING and WITH CHECK OPTIONS issues later, but it looks to me like
> that needs more study.

Sure, I will look into that.

-- 
Amit Langote
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Why is specifying oids = false multiple times in create table is silently ignored?
Next
From: Bharath Rupireddy
Date:
Subject: Re: Can we remove extra memset in BloomInitPage, GinInitPage and SpGistInitPage when we have it in PageInit?