pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>
Cc: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: partition routing layering in nodeModifyTable.c
Date: Wed, 14 Oct 2020 12:04:06 +0300
Message-ID: <902a656d-e4f2-70bf-f30f-1796d65791fe@iki.fi> (raw)
In-Reply-To: <CA+HiwqEHechwotq=Lo0PRwZ7AP9fNQQnnJMYFYVDAOr09SrYKw@mail.gmail.com>
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>

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





view thread (84+ messages)  latest in thread

Message-ID: <902a656d-e4f2-70bf-f30f-1796d65791fe@iki.fi>
Permalink:  ../902a656d-e4f2-70bf-f30f-1796d65791fe@iki.fi/
Also on:    postgresql.org/message-id/902a656d-e4f2-70bf-f30f-1796d65791fe@iki.fi

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: hlinnaka@iki.fi, amitlangote09@gmail.com, daniel@yesql.se, etsuro.fujita@gmail.com, andres@anarazel.de
  Subject: Re: partition routing layering in nodeModifyTable.c
  In-Reply-To: <902a656d-e4f2-70bf-f30f-1796d65791fe@iki.fi>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox