Re: [HACKERS] path toward faster partition pruning

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