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. > > Thanks > -Amit Khandekar -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
