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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
