On 2016/09/27 15:44, Ashutosh Bapat wrote: >> By the way, I fixed one thinko in your patch as follows: >> >> - result->oids[i] = oids[mapping[i]]; >> + result->oids[mapping[i]] = oids[i]; > > While I can not spot any problem with this logic, when I make that > change and run partition_join testcase in my patch, it fails because > wrong partitions are matched for partition-wise join of list > partitions. In that patch, RelOptInfo of partitions are saved in > RelOptInfo of the parent by matching their OIDs. They are saved in the > same order as corresponding OIDs. Partition-wise join simply joins the > RelOptInfos at the same positions from both the parent RelOptInfos. I > can not spot an error in this logic too.
OTOH, using the original logic makes tuple routing put tuples into the wrong partitions. When debugging why that was happening I discovered this and hence the proposed change. You mean that partition RelOptInfo's are placed using the canonical ordering of OIDs instead of catalog-scan-driven order, right? If that's true, then there is no possibility of wrong pairing happening, even with the new ordering of OIDs in the partition descriptor (ie, the ordering that would be produced by my proposed method above). Thanks, Amit -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers