Re: executor relation handling - Mailing list pgsql-hackers

From Amit Langote
Subject Re: executor relation handling
Date
Msg-id 5d1b16f9-0c8b-1798-e7c7-8991d2a15b06@lab.ntt.co.jp
Whole thread Raw
In response to Re: executor relation handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: executor relation handling  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2018/10/08 3:55, Tom Lane wrote:
> I didn't like the idea of unifying ModifyTable.nominalRelation with
> the partition root info.  Those fields serve different masters ---
> nominalRelation, at least in its original intent, is only meant for
> use of EXPLAIN and might have nothing to do with what happens at
> execution.  So even though unifying them would work today, we might
> regret it down the line.  Instead I left that field alone and added
> a separate rootRelation field to carry the partition root RT index,
> which ends up being the same number of fields anyway since we don't
> need a flag for is-the-nominal-relation-a-partition-root.

Thanks for pushing that.  I'd also named it 'rootRelation' in my original
patch before David had objected to calling it that, because a command may
not specify the "actual" root of a partition tree; it could be a non-root
partitioned table.  He'd suggested 'partitionedTarget' for the new field
[1], stressing the "target" part.  Maybe, 'rootRelation' isn't too
confusing though.

Thanks,a
Amit

[1]
https://www.postgresql.org/message-id/CAKJS1f_M0jkgL-d%3Dk-rf6TMzghATDmZ67nzja1tz4h3G%3D27e7Q%40mail.gmail.com




pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: executor relation handling
Next
From: Pavel Stehule
Date:
Subject: Re: merge semi join cost calculation error