On Sun, Feb 25, 2018 at 11:10 PM, Amit Langote
<Langote_Amit_f8@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