On Tue, Jul 3, 2018 at 3:20 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
>
> Maybe because that's what's done for the root parent in a plain
> inheritance hierarchy, which is always a plain table. In that case, one
> RTE is for its role as the parent (with rte->inh = true) and another is
> for its role as a child (with rte->inh = false). The former is processed
> as an append rel and the latter as a plain rel that will get assigned scan
> paths such as SeqScan, etc.
Yes that's true. I remember we had some discussion about these two
RTEs and that the one marked as child was extraneous, but I can not
spot that in the mail thread. It's one of the things we did as part of
partition-wise join and that thread is pretty long. It was probably
kept without changing it because a. we wanted to get the bigger patch
committed without breaking anything and this was a small thing which
we couldn't decide whether was safe or not b. if it was safe not to
create that entry, it should have been done in a commit which avoided
creating scans for partitioned tables, but didn't
>
> For partitioned table parent(s), we need only the former because they can
> only be processed as append rels. That's why I'm proposing we could
> adjust the commit in PG 11 that introduced expand_partitioned_rtentry such
> that the duplicate child RTE and other objects are not created.
FWIW, I think this would be ok before beta, but not now. I see it as a
PG12 item.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
