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
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 |