Hello,
> > Yes, the old dumped version of typ2 patch did so. It flattened
> > appendrel tree for the query prpoerly. Let me hear the reson you
> > prefer to do so.
>
> Having reviewed my upthread reasoning for preferring one of those two
> approaches over the other, it's a weak preference. They have similar runtime
> costs. Putting the logic with the code that creates appendrels reduces the
> number of code sites one must examine to reason about possible plan
> structures. We might not flatten RTE_RELATION appendrel parents exactly the
> same way we flatten RTE_SUBQUERY appendrel parents. I would tend to leave
> inh=true for the former, for reasons explained in my notes on v7, but set
> inh=false for the latter to save needless work.
Unfortunately, RTE_SUBQUERY-es with their inh flag cleard might
cause something inconvenient in preprocess_minmax_aggregates()
and/or add_rtes_to_flat_rtable()..
# I haven't found that related to sepgsql, though :-(
I understood that your concern is to deal parent RTEs defferently
according to their relkinds. But I think the inh flags could not
be modified at all for the reason mentioned above.
Finally the seemingly most safe way to exclude removed
intermediate RTEs in subsequent processing is simplly remove
apprelinfos directly linked to them (as did in v7), for both of
the parents, RTE_RELATION and RTE_SUBQUERY. The difference has
disappeared in this story.
At least as of now, inheritance tables define the bottom bound of
a appendrel tree and on the other hand complex(?) union_alls
define the upper bound, and both multilevel (simple)union_alls
and inheritances are flattened individually so all possible
inheritance tree to be collapsed by this patch is only, I think,
Subquery(inh=1)[Relation-inhparent [Relation-child, child, child]]
> On the other hand, a flattening pass is less code overall and
> brings an attractive uniformity-by-default to the area.
Focusing only on the above structure, what we should do to
collapse this tree is only connect the childs to the Subquery
directly, then remove all appendrelinfos connecting to the
Relation-inhparent. inh flag need not to be modified.
# Umm. I strongly suspect that I overlooked something..
Then even widening to general case, the case doesn't seem to
change. All we need to do is, link a child to its grandparent and
isolate the parent removing apprelinfos.
Thoughts?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center