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:amitlangot...@gmail.com] > Sent: Monday, July 8, 2019 11:34 AM > To: Kato, Sho/加藤 翔 <kato-...@jp.fujitsu.com> > Cc: David Rowley <david.row...@2ndquadrant.com>; PostgreSQL Hackers > <pgsql-hackers@lists.postgresql.org> > Subject: Re: Run-time pruning for ModifyTable > > Kato-san, > > On Thu, Jul 4, 2019 at 1:40 PM Kato, Sho <kato-...@jp.fujitsu.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
