Re: ModifyTable overheads in generic plans

Amit Langote <amitlangote09@gmail.com>

From: Amit Langote <amitlangote09@gmail.com>

To: Heikki Linnakangas <hlinnaka@iki.fi>

Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, David Rowley <dgrowleyml@gmail.com>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>

Date: 2020-12-22T08:16:46Z

Lists: pgsql-hackers

Attachments

v12-0001-Set-ForeignScanState.resultRelInfo-lazily.patch (application/octet-stream) patch v12-0001
v12-0002-Rethink-ResultRelInfo.ri_PartitionRoot.patch (application/octet-stream) patch v12-0002
v12-0003-Initialize-result-relation-information-lazily.patch (application/octet-stream) patch v12-0003

On Mon, Dec 7, 2020 at 3:53 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Nov 12, 2020 at 5:04 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > Attached new 0002 which does these adjustments.  I went with
> > ri_RootTargetDesc to go along with ri_RelationDesc.
> >
> > Also, I have updated the original 0002 (now 0003) to make
> > GetChildToRootMap() use ri_RootTargetDesc instead of
> > ModifyTableState.rootResultRelInfo.ri_RelationDesc, so that even
> > AfterTriggerSaveEvent() can now use that function.  This allows us to
> > avoid having to initialize ri_ChildToRootMap anywhere but inside
> > GetChildRootMap(), with that long comment defending doing so. :-)
>
> These needed to be rebased due to recent copy.c upheavals.  Attached.

Needed to be rebased again.

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

Commits

Comment cleanup for a1115fa07.
- 0d46771eaaf7 14.0 landed
Postpone some more stuff out of ExecInitModifyTable.
- a1115fa07823 14.0 landed
Postpone some stuff out of ExecInitModifyTable.
- c5b7ba4e67ae 14.0 landed