On Sun, Feb 25, 2018 at 11:10 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > I think I'm convinced that partopcintype OIDs can be used where I thought > parttypid ones were necessary. The pruning patch uses the respective OID > from this array when extracting the datum from an OpExpr to be compared > with the partition bound datums. It's sensible, I now think, to require > the extracted datum to be of partition opclass declared input type, rather > than the type of the partition key involved. So, I removed the parttypid > that I'd added to PartitionSchemeData. > > Updated the comments to make clear the distinction between and purpose of > having both parttypcoll and partcollation. Also expanded the comment > about partsupfunc a bit.
I don't think this fundamentally fixes the problem, although it does narrow it. By requiring partcollation to match across every relation with the same PartitionScheme, you're making partition-wise join fail to work in some cases where it previously did. Construct a test case where parttypcoll matches and partcollation doesn't; then, without the patch, the two relations will have the same PartitionScheme and thus be eligible for a partition-wise join, but with the patch, they will have different PartitionSchemes and thus won't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
