Re: Run-time pruning for ModifyTable - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Run-time pruning for ModifyTable
Date
Msg-id CA+HiwqExqX6mAX2RqqHb5svCmxgq=f8ahN0dXnTv1OnV4ritsA@mail.gmail.com
Whole thread Raw
In response to Re: Run-time pruning for ModifyTable  (David Rowley <david.rowley@2ndquadrant.com>)
Responses RE: Run-time pruning for ModifyTable  ("Kato, Sho" <kato-sho@jp.fujitsu.com>)
List pgsql-hackers
On Wed, Jul 3, 2019 at 4:34 PM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On Wed, 3 Jul 2019 at 17:27, Amit Langote <amitlangote09@gmail.com> wrote:
> > A cursory look at the patch suggests that most of its changes will be
> > for nothing if [1] materializes.  What do you think about that?
>
> Yeah, I had this in mind when writing the patch, but kept going
> anyway.  I think it's only really a small patch of this patch that
> would get wiped out with that change. Just the planner.c stuff.
> Everything else is still required, as far as I understand.

If I understand the details of [1] correctly, ModifyTable will no
longer have N subplans for N result relations as there are today.  So,
it doesn't make sense for ModifyTable to contain
PartitionedRelPruneInfos and for ExecInitModifyTable/ExecModifyTable
to have to perform initial and execution-time pruning, respectively.
As I said, bottom expansion of target inheritance will mean pruning
(both plan-time and run-time) will occur at the bottom too, so the
run-time pruning capabilities of nodes that already have it will be
used for UPDATE and DELETE too.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: Re: FETCH FIRST clause WITH TIES option
Next
From: Haribabu Kommi
Date:
Subject: Re: MSVC Build support with visual studio 2019