Re: Run-time pruning for ModifyTable

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, 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-03-25 02:36:52
Message-ID: CA+HiwqH31yfQF6LV_mF75q7T4AdS93ofywdph0Jgk3TDuCXr7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi David,

Sorry I couldn't get to this sooner.

On Wed, Mar 25, 2020 at 9:49 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Wed, 25 Mar 2020 at 13:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > > I had a closer look at this today and the code I have in
> > > inheritance_planner() is certainly not right.
> >
> > Although I didn't get around to it for v13, there's still a plan on the
> > table for inheritance_planner() to get nuked from orbit [1].
> >
> > Maybe this improvement should be put on hold till that's done?
>
> Possibly. I'm not really wedded to the idea of getting it in. However,
> it would really only be the inheritance planner part that would need
> to be changed later. I don't think any of the other code would need to
> be adjusted.
>
> Amit shared his thoughts in [1]. If you'd rather I held off, then I will.
>
> David
>
> [1] https://www.postgresql.org/message-id/CA%2BHiwqGhD7ieKsv5%2BGkmHgs-XhP2DoUhtESVb3MU-4j14%3DG6LA%40mail.gmail.com

Actually, I was saying in that email that the update/delete planning
overhaul being talked about will make the entirety of the
functionality this patch is adding, which is ModifyTable node being
able to prune its subplans based on run-time parameter values,
redundant. That's because, with the overhaul, there won't be multiple
subplans under ModifyTable, only one which would take care of any
pruning that's necessary.

What I did say in favor of this patch though is that it doesn not seem
that invasive, so maybe okay to get in for v13.

--
Thank you,

Amit Langote
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Sharpe 2020-03-25 02:49:55 [PATCH] Fix CommitTransactionCommand() to CallXactCallbacks() in TBLOCK_ABORT_END
Previous Message Thomas Munro 2020-03-25 02:27:06 Re: some AppVeyor files