RE: Run-time pruning for ModifyTable

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
>

In response to

Responses

Browse pgsql-hackers by date

  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