| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: executor relation handling |
| Date: | 2018-10-09 06:26:34 |
| Message-ID: | 5d1b16f9-0c8b-1798-e7c7-8991d2a15b06@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2018-10-09 06:30:42 | Re: merge semi join cost calculation error |
| Previous Message | Amit Langote | 2018-10-09 06:11:38 | Re: executor relation handling |