On Tue, Sep 27, 2016 at 2:46 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > 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).
right! I don't know what's wrong, will debug my changes. -- Best Wishes, Ashutosh Bapat 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
