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:amitlangot...@gmail.com] > Sent: Wednesday, July 3, 2019 5:41 PM > To: David Rowley <david.row...@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.row...@2ndquadrant.com> > wrote: > > On Wed, 3 Jul 2019 at 17:27, Amit Langote <amitlangot...@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 >