Re: partition routing layering in nodeModifyTable.c

Amit Langote <amitlangote09@gmail.com>

From: Amit Langote <amitlangote09@gmail.com>

To: Heikki Linnakangas <hlinnaka@iki.fi>

Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Daniel Gustafsson <daniel@yesql.se>, Etsuro Fujita <etsuro.fujita@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2020-10-22T13:49:14Z

Lists: pgsql-hackers

Attachments

v1-0002-Initialize-ForeignScanState.resultRelInfo-in-Exec.patch (application/octet-stream) patch v1-0002
v1-0001-Fix-a-thinko-of-1375422c782.patch (application/octet-stream) patch v1-0001
v1-0003-Initialize-result-relation-information-lazily.patch (application/octet-stream) patch v1-0003

On Tue, Oct 20, 2020 at 9:57 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Mon, Oct 19, 2020 at 8:55 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > It's probably true that there's no performance gain from initializing
> > them more lazily. But the reasoning and logic around the initialization
> > is complicated. After tracing through various path through the code, I'm
> > convinced enough that it's correct, or at least these patches didn't
> > break it, but I still think some sort of lazy initialization on first
> > use would make it more readable. Or perhaps there's some other
> > refactoring we could do.
>
> So the other patch I have mentioned is about lazy initialization of
> the ResultRelInfo itself, not the individual fields, but maybe with
> enough refactoring we can get the latter too.

So, I tried implementing a lazy-initialization-on-first-access
approach for both the ResultRelInfos themselves and some of the
individual fields of ResultRelInfo that don't need to be set right
away.  You can see the end result in the attached 0003 patch.  This
slims down ExecInitModifyTable() significantly, both in terms of code
footprint and the amount of work that it does.

0001 fixes a thinko of the recent commit 1375422c782 that I discovered
when debugging a problem with 0003.

0002 is for something I have mentioned upthread.
ForeignScanState.resultRelInfo cannot be set in ExecInit* stage as
it's done now, because with 0003, child ResultRelInfos will not have
been added to es_result_relations during that stage.

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

Commits

Fix initialization of es_result_relations in EvalPlanQualStart().
- 22b73d3cb0b5 14.0 landed
Remove PartitionRoutingInfo struct.
- fb5883da8615 14.0 landed
Revise child-to-root tuple conversion map management.
- 6973533650c0 14.0 landed
Clean up code to resolve the "root target relation" in nodeModifyTable.c
- f49b85d783f6 14.0 landed
Refactor code for cross-partition updates to a separate function.
- c5b097f8fa69 14.0 landed
Remove es_result_relation_info from EState.
- a04daa97a433 14.0 landed
Include result relation info in direct modify ForeignScan nodes.
- 178f2d560dde 14.0 landed
Create ResultRelInfos later in InitPlan, index them by RT index.
- 1375422c7826 14.0 landed