Sorry, I didn't notice this email until now.
On Wed, Nov 27, 2019 at 5:17 PM Michael Paquier <michael@paquier.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@2ndquadrant.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
