On Thu, Aug 31, 2017 at 3:36 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> ISTM, the primary motivation for the EIBO patch at this point is to get
> the partitions ordered in a predictable manner so that the partition-wise
> join patch and update partition key patches could implement certain logic
> using O (n) algorithm rather than an O (n^2) one.
That's part of it, but not the whole thing. For example, BASIC
partition-wise join only needs a predictable order, not a
bound-ordered one. But the next step is to be able to match up uneven
bounds - e.g. given [1000, 2000), [3000, 4000), [5000, 6000) on one
side and [1100, 2100), [2900,3900), and [5500,5600) on the other side,
we can still make it work. That greatly benefits from being able to
iterate through all the bounds in order.
> Neither of them depend
> on the actual order in the sense of, say, sticking a PathKey to the
> resulting Append. Perhaps, the patch to"Make the optimiser aware of
> partitions ordering" [1] will have to consider this somehow; maybe by
> limiting its scope to only the cases where the root partitioned table is
> range partitioned.
I think that doing a depth-first traversal as I've done here avoids
the need to limit it to that case. If we did a breadth-first
traversal anything that was subpartitioned would end up having the
subpartitions at the end instead of in the sequence, but the
depth-first traversal avoids that issue.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company