On 31 August 2017 at 13:06, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> Mind you, that idea has some problems anyway in the face of default >> partitions, null partitions, and list partitions which accept >> non-contiguous values (e.g. one partition for 1, 3, 5; another for 2, >> 4, 6). We might need to mark the PartitionDesc to indicate whether >> PartitionDesc-order is in fact bound-order in a particular instance, >> or something like that. > > 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. Neither of them depend > on the actual order in the sense of, say, sticking a PathKey to the > resulting Append.
Now that the inheritance hierarchy is expanded in depth-first order, RelationGetPartitionDispatchInfo() needs to be changed to arrange the PartitionDispatch array and the leaf partitions in depth-first order (as we know this is a requirement for the update-partition-key patch for efficiently determining which of the leaf partitions are already present in the update result rels). Amit, I am not sure if you are already doing this as part of the patches in this mail thread. Please let me know. Also, let me know if you think there will be any loss of efficiency in tuple routing code if we arrange the Partition Dispatch indexes in depth-first order. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
