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
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? |