Hi, Amit
> If I understand the details of [1] correctly, ModifyTable will no longer
> have N subplans for N result relations as there are today. So, it doesn't
> make sense for ModifyTable to contain PartitionedRelPruneInfos and for
> ExecInitModifyTable/ExecModifyTable
> to have to perform initial and execution-time pruning, respectively.
Does this mean that the generic plan will not have N subplans for N result relations?
I thought [1] would make creating generic plans faster, but is this correct?
regards,
kato sho
> -----Original Message-----
> From: Amit Langote [mailto:amitlangote09@gmail.com]
> Sent: Wednesday, July 3, 2019 5:41 PM
> To: David Rowley <david.rowley@2ndquadrant.com>
> Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
> Subject: Re: Run-time pruning for ModifyTable
>
> On Wed, Jul 3, 2019 at 4:34 PM David Rowley <david.rowley@2ndquadrant.com>
> wrote:
> > On Wed, 3 Jul 2019 at 17:27, Amit Langote <amitlangote09@gmail.com>
> wrote:
> > > A cursory look at the patch suggests that most of its changes will
> > > be for nothing if [1] materializes. What do you think about that?
> >
> > Yeah, I had this in mind when writing the patch, but kept going
> > anyway. I think it's only really a small patch of this patch that
> > would get wiped out with that change. Just the planner.c stuff.
> > Everything else is still required, as far as I understand.
>
> If I understand the details of [1] correctly, ModifyTable will no longer
> have N subplans for N result relations as there are today. So, it doesn't
> make sense for ModifyTable to contain PartitionedRelPruneInfos and for
> ExecInitModifyTable/ExecModifyTable
> to have to perform initial and execution-time pruning, respectively.
> As I said, bottom expansion of target inheritance will mean pruning (both
> plan-time and run-time) will occur at the bottom too, so the run-time
> pruning capabilities of nodes that already have it will be used for UPDATE
> and DELETE too.
>
> Thanks,
> Amit
>
