Re: ModifyTable overheads in generic plans

Amit Langote <amitlangote09@gmail.com>

From: Amit Langote <amitlangote09@gmail.com>

To: Robert Haas <robertmhaas@gmail.com>

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

Date: 2020-10-30T06:13:46Z

Lists: pgsql-hackers

Attachments

v6-0001-Call-BeginDirectModify-from-ExecInitModifyTable.patch (application/octet-stream) patch v6-0001
v6-0002-Initialize-result-relation-information-lazily.patch (application/octet-stream) patch v6-0002

Attached updated patches based on recent the discussion at:

* Re: partition routing layering in nodeModifyTable.c *
https://www.postgresql.org/message-id/CA%2BHiwqHpmMjenQqNpMHrhg3DRhqqQfby2RCT1HWVwMin3_5vMA%40mail.gmail.com

0001 adjusts how ForeignScanState.resultRelInfo is initialized for use
by direct modify operations.

0002 refactors ResultRelInfo initialization do be don lazily on first use

I call these v6, because the last version posted on this thread was
v5, even though it went through a couple of iterations on the above
thread. Sorry about the confusion.

-- 
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