On Thu, Sep 7, 2017 at 6:17 AM, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 3 September 2017 at 17:10, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> After recent commit 30833ba154, now the partitions are expanded in >> depth-first order. It didn't seem worthwhile rebasing my partition >> walker changes onto the latest code. So in the attached patch, I have >> removed all the partition walker changes. But >> RelationGetPartitionDispatchInfo() traverses in breadth-first order, >> which is different than the update result rels order (because >> inheritance expansion order is depth-first). So, in order to make the >> tuple-routing-related leaf partitions in the same order as that of the >> update result rels, we would have to make changes in >> RelationGetPartitionDispatchInfo(), which I am not sure whether it is >> going to be done as part of the thread "expanding inheritance in >> partition bound order" [1]. For now, in the attached patch, I have >> reverted back to the hash table method to find the leaf partitions in >> the update result rels. >> >> [1] >> https://www.postgresql.org/message-id/CAJ3gD9eyudCNU6V-veMme%2BeyzfX_ey%2BgEzULMzOw26c3f9rzdg%40mail.gmail.com > > As mentioned by Amit Langote in the above mail thread, he is going to > do changes for making RelationGetPartitionDispatchInfo() return the > leaf partitions in depth-first order. Once that is done, I will then > remove the hash table method for finding leaf partitions in update > result rels, and instead use the earlier efficient method that takes > advantage of the fact that update result rels and leaf partitions are > in the same order.
Has he posted that patch yet? I don't think I saw it, but maybe I missed something. -- 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
