On Wed, Aug 30, 2017 at 9:22 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > Amit's patches seem to be addressing the third point here. But the > expansion is not happening in breadth-first manner. We are expanding > all the partitioned partitions first and then leaf partitions. So > that's not exactly "breadth-first".
Correct, but I think Amit's ordering is what we actually want: breadth-first, low-OID-first over interior partitioned tables, and then breadth-first, low-OID-first again over leaves. If we don't keep partitioned partitions first, then we're going to have problems keeping the locking order consistent when we start doing pruning during expansion. > A better way for translating partition hierarchy into inheritance > hierarchy may be to expand all partitions (partitioned or leaf) of a > given parent at a time in breadth-first manner. This allows us to > create child RTE, AppendRelInfo, rowmarks while we have corresponding > parent structures at hand, rather than searching for those. This would > still satisfy Amit Khandekar's requirement to expand leaf partitions > in the same order as their OIDs would be returned by > RelationGetPartitionDispatchInfo(). I have a feeling that, if we go > that route, we will replace almost all the changes that Amit Langote's > patches do to expand_inherited_rtentry(). I think we will, too, but I think that's basically the problem of the partition-wise join patch. Either find_all_inheritors is going to have to return enough additional information to let expand_inherited_rtentry work efficiently, or else expand_inherited_rtentry is going to have to duplicate some of the logic from find_all_inheritors. But that doesn't make what Amit is doing here a bad idea -- getting stuff that shouldn't be part of PartitionDispatch removed and getting the expansion order in expand_inherited_rtentry() changed seem to be the right things to do even if the way it's implemented has to be revised to meet other goals. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
