RE: Run-time pruning for ModifyTable - Mailing list pgsql-hackers

From Kato, Sho
Subject RE: Run-time pruning for ModifyTable
Date
Msg-id 25C1C6B2E7BE044889E4FE8643A58BA972683DD4@G01JPEXMBKW03
Whole thread Raw
In response to Re: Run-time pruning for ModifyTable  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
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@gmail.com]
> Sent: Monday, July 8, 2019 11:34 AM
> To: Kato, Sho/加藤 翔 <kato-sho@jp.fujitsu.com>
> Cc: David Rowley <david.rowley@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-sho@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

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: allow_system_table_mods stuff
Next
From: Thomas Munro
Date:
Subject: Re: Add test case for sslinfo