Re: Run-time pruning for ModifyTable

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Kato, Sho" <kato-sho(at)jp(dot)fujitsu(dot)com>
Subject: Re: Run-time pruning for ModifyTable
Date: 2020-01-23 07:31:12
Message-ID: CA+HiwqGhD7ieKsv5+GkmHgs-XhP2DoUhtESVb3MU-4j14=G6LA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sorry, I didn't notice this email until now.

On Wed, Nov 27, 2019 at 5:17 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Tue, Nov 05, 2019 at 04:04:25PM +1300, Thomas Munro wrote:
> > On Thu, Sep 12, 2019 at 10:10 AM Alvaro Herrera
> > <alvherre(at)2ndquadrant(dot)com> wrote:
> > > Here's a rebased version of this patch (it had a trivial conflict).
> >
> > Hi, FYI partition_prune.sql currently fails (maybe something to do
> > with commit d52eaa09?):
>
> David, perhaps you did not notice that? For now I have moved this
> patch to next CF waiting on author to look after the failure.
>
> Amit, Kato-san, both of you are marked as reviewers of this patch.
> Are you planning to look at it?

Sorry, I never managed to look at the patch closely. As I commented
up-thread, the functionality added by this patch would be unnecessary
if we were to move forward with the other project related to UPDATE
and DELETE over inheritance trees:

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

I had volunteered to submit a patch in that thread and even managed to
write one but didn't get time to get it in good enough shape to post
it to the list, like I couldn't make it handle foreign child tables.
The gist of the new approach is that ModifyTable will always have
*one* subplan under ModifyTable, not N for N target partitions as
currently. That one subplan being the same plan as one would get if
the query were SELECT instead of UPDATE/DELETE, it would automatically
take care of run-time pruning if needed, freeing ModifyTable itself
from having to do it.

Now, the chances of such a big overhaul of how UPDATEs of inheritance
trees are handled getting into PG 13 seem pretty thin even if I post
the patch in few days, so perhaps it would make sense to get this
patch in so that we can give users run-time pruning for UPDATE/DELETE
in PG 13, provided the code is not very invasive. If and when the
aforesaid overhaul takes place, that code would go away along with a
lot of other code.

Thanks,
Amit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Malthe 2020-01-23 07:39:21 Re: Index-only scan for "f(x)" without "x"
Previous Message Michael Paquier 2020-01-23 07:04:51 Re: Do we need to handle orphaned prepared transactions in the server?