Subject: Re: partition routing layering in nodeModifyTable.c
To: Amit Langote <amitlangote09@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>,
 Etsuro Fujita <etsuro.fujita@gmail.com>, Andres Freund <andres@anarazel.de>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <20190718010911.l6xcdv6birtxiei4@alap3.anarazel.de>
 <424F4298-7826-40DC-B12B-37EFE60EE243@yesql.se>
 <CA+HiwqFaXvPRpYjuw_x5jFvL7XtAH2kXCRaWAg3N+5ppfyr4fw@mail.gmail.com>
 <73fe6ce6-d2a1-bd4b-17cf-9deba4e91467@iki.fi>
 <CA+HiwqGAVa9J9hNLH7tVCs13UqJMP-9RU_T5uAWEAfsg8VEXGQ@mail.gmail.com>
 <19c23dd9-89ce-75a3-9105-5fc05a46f94a@iki.fi>
 <CA+HiwqHtriD3HquH5=uT5caHd4jiEoxeb5JD2JSZRm8gDXsRxw@mail.gmail.com>
 <CA+HiwqGEmiib8FLiHMhKB+CH5dRgHSLc5N5wnvc4kym+ZYpQEQ@mail.gmail.com>
 <9bfb949e-21b6-e0f7-c9c9-58710d11e7b1@iki.fi>
 <CA+HiwqHX4gt6b7e=xM3aG837Hfv=q5hEkQ=E1BSi54ob=_cQaA@mail.gmail.com>
 <3603af69-eb52-4891-5d50-669cb03090a6@iki.fi>
 <CA+HiwqENbJMzoD1VAoNWFLcnam0zJS34Vy0o5AuhW-UVq1LV6A@mail.gmail.com>
 <ddae2239-4932-fb08-e501-9768cee871fc@iki.fi>
 <CA+HiwqGCiipPyFLSvO9K=xbT2yPb2EPN1OTi-YMBgOR7UEuaQA@mail.gmail.com>
 <a7e25ec8-4c46-1636-1a96-0c38fa5fde96@iki.fi>
 <be90708f-9717-fb37-9cc1-d2482f7e4230@iki.fi>
 <CA+HiwqEHechwotq=Lo0PRwZ7AP9fNQQnnJMYFYVDAOr09SrYKw@mail.gmail.com>
From: Heikki Linnakangas <hlinnaka@iki.fi>
Message-ID: <902a656d-e4f2-70bf-f30f-1796d65791fe@iki.fi>
Date: Wed, 14 Oct 2020 12:04:06 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: 
 <CA+HiwqEHechwotq=Lo0PRwZ7AP9fNQQnnJMYFYVDAOr09SrYKw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 14/10/2020 09:44, Amit Langote wrote:
> I like the idea of storing the ResultRelInfo in ForeignScanState, but
> it would be better if we can document the fact that an FDW may not
> reliably access until IterateDirectModify(). That's because, setting
> it in ExecInitForeignScan() will mean *all* result relations must be
> initialized during ExecInitModifyTable(), which defies my
> lazy-ResultRelInfo-initiailization proposal.  As to why why I'm
> pushing that proposal, consider that when we'll get the ability to use
> run-time pruning for UPDATE/DELETE with [1], initializing all result
> relations before initializing the plan tree will mean most of those
> ResultRelInfos will be unused, because run-time pruning that occurs
> when the plan tree is initialized (and/or when it is executed) may
> eliminate most but a few result relations.
> 
> I've attached a diff to v17-0001 to show one way of delaying setting
> ForeignScanState.resultRelInfo.

The BeginDirectModify function does a lot of expensive things, like 
opening a connection to the remote server. If we want to optimize 
run-time pruning, I think we need to avoid calling BeginDirectModify for 
pruned partitions altogether.

I pushed this without those delay-setting-resultRelInfo changes. But we 
can revisit those changes with the run-time pruning optimization patch.

I'll continue with the last couple of patches in this thread.

- Heikki