On Wed, Aug 30, 2017 at 9:22 AM, Ashutosh Bapat
<ashutosh.bapat@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