RE: Run-time pruning for ModifyTable

On Monday, July 8, 2019 11:34 AM, Amit Langote wrote:
> By the way, let's keep any further discussion on this particular topic
> in the other thread.

Thanks for the details. I got it.

Regards,
Kato sho
> -----Original Message-----
> From: Amit Langote [mailto:amitlangote09(at)gmail(dot)com]
> Sent: Monday, July 8, 2019 11:34 AM
> To: Kato, Sho/加藤 翔 <kato-sho(at)jp(dot)fujitsu(dot)com>
> Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>; PostgreSQL Hackers
> <pgsql-hackers(at)lists(dot)postgresql(dot)org>
> Subject: Re: Run-time pruning for ModifyTable
>
> Kato-san,
>
> On Thu, Jul 4, 2019 at 1:40 PM Kato, Sho <kato-sho(at)jp(dot)fujitsu(dot)com> wrote:
> > > 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?
>
> Yeah, making a generic plan for UPDATE of inheritance tables will
> certainly become faster, because we will no longer plan the same query
> N times for N child tables. There will still be N result relations but
> only one sub-plan to fetch the rows from. Also, planning will still cost
> O(N), but with a much smaller constant factor.
>
> By the way, let's keep any further discussion on this particular topic
> in the other thread.
>
> Thanks,
> Amit