On Fri, Aug 18, 2017 at 1:17 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > 0004 patch in partition-wise join patchset has code to expand > partition hierarchy. That patch is expanding inheritance hierarchy in > depth first manner. Robert commented that instead of depth first > manner, it will be better if we expand it in partitioned tables first > manner. With the latest changes in your patch-set I don't see the > reason for expanding in partitioned tables first order. Can you please > elaborate if we still need to expand in partitioned table first > manner? May be we should just address the expansion issue in 0004 > instead of dividing it in two patches.
Let me see if I can clarify. I think there are three requirements here: A. Amit wants to be able to prune leaf partitions before opening and locking those relations, so that pruning can be done earlier and, therefore, more cheaply. B. Partition-wise join wants to expand the inheritance hierarchy a level at a time instead of all at once, ending up with rte->inh = true entries for intermediate partitioned tables. C. Partition-wise join (and lots of other things; see numerous mentions of EIBO in http://rhaas.blogspot.com/2017/08/plans-for-partitioning-in-v11.html) want to expand in bound order. Obviously, bound-order and partitioned-tables-first are incompatible orderings, but there's no actual conflict because the first one has to do with the order of *expansion* and the second one has to do with the order of *locking*. So in the end game I think expand_inherited_rtentry looks approximately like this: 1. Calling find_all_inheritors with a new only-lock-the-partitions flag. This should result in locking all partitioned tables in the inheritance hierarchy in breadth-first, low-OID-first order. (When the only-lock-the-partitions isn't specified, all partitioned tables should still be locked before any unpartitioned tables, so that the locking order in that case is consistent with what we do here.) 2. Iterate over the partitioned tables identified in step 1 in the order in which they were returned. For each one: - Decide which children can be pruned. - Lock the unpruned, non-partitioned children in low-OID-first order. 3. Make another pass over the inheritance hierarchy, starting at the root. Traverse the whole hierarchy in breadth-first in *bound* order. Add RTEs and AppendRelInfos as we go -- these will have rte->inh = true for partitioned tables and rte->inh = false for leaf partitions. Whether we should try to go straight to the end state here or do this via a series of incremental changes, I'm not entirely sure right now. -- 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
