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