From: | "Kato, Sho" <kato-sho(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Amit Langote' <amitlangote09(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Run-time pruning for ModifyTable |
Date: | 2019-07-04 04:40:44 |
Message-ID: | 25C1C6B2E7BE044889E4FE8643A58BA972682349@G01JPEXMBKW03 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)gmail(dot)com]
> Sent: Wednesday, July 3, 2019 5:41 PM
> To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
> Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
> Subject: Re: Run-time pruning for ModifyTable
>
> On Wed, Jul 3, 2019 at 4:34 PM David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
> wrote:
> > On Wed, 3 Jul 2019 at 17:27, Amit Langote <amitlangote09(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2019-07-04 05:57:19 | Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) |
Previous Message | David Rowley | 2019-07-04 03:43:31 | Re: Tid scan improvements |