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

From Amit Langote
Subject Re: Run-time pruning for ModifyTable
Date
Msg-id CA+HiwqE3--u1OaZ+6YEt_R__hXGqccovQe+Y1_8rUMkmObTGTw@mail.gmail.com
Whole thread Raw
In response to Run-time pruning for ModifyTable  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Run-time pruning for ModifyTable  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
Hi David,

On Thu, Jun 27, 2019 at 2:28 PM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> Deja vu from this time last year when despite everyone's best efforts
> (mostly Alvaro) we missed getting run-time pruning in for MergeAppend
> into the PG11 release.   This year it was ModifyTable, which is now
> possible thanks to Amit and Tom's modifications to the inheritance
> planner.
>
> I've attached what I have so far for this.

Thanks for working on this.  IIUC, the feature is to skip modifying a
given result relation if run-time pruning dictates that none of its
existing rows will match some dynamically computable quals.

>  I think it's mostly okay,
> but my brain was overheating a bit at the inheritance_planner changes.

I think we need to consider the fact that there is a proposal [1] to
get rid of inheritance_planner() as the way of planning UPDATE/DELETEs
on inheritance trees.  If we go that route, then a given partitioned
target table will be expanded at the bottom and so, there's no need
for ModifyTable to have its own run-time pruning info, because
Append/MergeAppend will have it.  Maybe, we will need some code in
ExecInitModifyTable() and ExecModifyTable() to handle the case where
run-time pruning, during plan tree initialization and plan tree
execution respectively, may have rendered modifying a given result
relation unnecessary.

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?

Thanks,
Amit

[1] https://www.postgresql.org/message-id/357.1550612935%40sss.pgh.pa.us



pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: extension patch of CREATE OR REPLACE TRIGGER
Next
From: Amit Langote
Date:
Subject: Re: Another way to fix inherited UPDATE/DELETE