Re: Run-time pruning for ModifyTable

From: Amit Langote <amitlangote09(at)gmail(dot)com>
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
Date: 2019-07-03 08:40:39
Message-ID: CA+HiwqExqX6mAX2RqqHb5svCmxgq=f8ahN0dXnTv1OnV4ritsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 Haribabu Kommi 2019-07-03 08:51:59 Re: MSVC Build support with visual studio 2019
Previous Message Erik Rijkers 2019-07-03 08:23:08 Re: FETCH FIRST clause WITH TIES option