Hello, > > Unfortunately, RTE_SUBQUERY-es with their inh flag cleard might > > cause something inconvenient in preprocess_minmax_aggregates() > > and/or add_rtes_to_flat_rtable().. > > preprocess_minmax_aggregates() only cares about RTEs reachable from the join > tree, and the appendrel parents made obsolete by flattening would not be > reachable from the join tree. add_rtes_to_flat_rtable() might be unhappy. > > > # 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. > > That's fine, then. It was a minor point.
Ya, anyway, inh's alterability during inheritance tree transformation is not a minor issue, if we choose flattening rather than equivalance adjustment (what typ1 patch did). > If you are convinced that a separate flattening pass is best, that suffices > for me at this stage. Please submit the patch you have in mind, incorporating > any improvements from the v7 patch that are relevant to both approaches. All right. > > 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. > > I barely follow what you're saying here. Do you speak of > union_inh_idx_typ2_v2_20131113.patch, unionall_inh_idx_typ3_v7.patch, or some > future design? Sorry, it's about some future design, but the point is inevitable if we select the 'flattening pass' way. > If we use a separate flattening pass, there's no small limit > on how many layers of appendrel we may need to flatten. pull_up_subqueries() > can create many nested RTE_SUBQUERY appendrel layers; there may be more than > just child, parent and grandparent. There's never more than one layer of > RTE_RELATION appendrel, though. Yes, that is near to my 'general case' I had in my mind something similar in the structure but different in the source to inheritance tables, but talking about such possibilities seems senseless. Now the 'general case' is exactly the same to what you mentioned above. On the other hand, Tom gave us a proposal to deal this in add_child_rel_equivalences(), it is similar at the entry to my old failed typ1 patch but more profound. I'll consider on this for now. 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
