On 2017/09/21 12:42, Robert Haas wrote:
> Associate partitioning information with each RelOptInfo.
> This is not used for anything yet, but it is necessary infrastructure
> for partition-wise join and for partition pruning without constraint
> exclusion.
> Ashutosh Bapat, reviewed by Amit Langote and with quite a few changes,
> mostly cosmetic, by me.  Additional review and testing of this patch
> series by Antonin Houska, Amit Khandekar, Rafia Sabih, Rajkumar
> Raghuwanshi, Thomas Munro, and Dilip Kumar.

I noticed that this commit does not add partcollation field to
PartitionSchemeData, while it adds parttypcoll.  I think it'd be necessary
to have partcollation too, because partitioning would have used the same,
not parttypcoll.  For, example see the following code in

        cmpval = DatumGetInt32(FunctionCall2Coll(&key->partsupfunc[i],

So, it would be wrong to use parttypcoll, if we are to use the collation
to match a clause with the partition bounds when doing partition-pruning.
Concretely, a clause's inputcollid should match partcollation for the
corresponding column, not the column's parttypcoll.

Attached is a patch that adds the same.  I first thought of including it
in the partition-pruning patch set [1], but thought we could independently
fix this.



[1] https://commitfest.postgresql.org/14/1272/
From 4e25d503a00c5fb42919e73aae037eacb0164af6 Mon Sep 17 00:00:00 2001
From: amit <amitlangot...@gmail.com>
Date: Wed, 27 Sep 2017 15:49:50 +0900
Subject: [PATCH 1/5] Add partcollation field to PartitionSchemeData

It copies PartitionKeyData.partcollation.  We need that in addition
to parttypcoll.
 src/backend/optimizer/util/plancat.c | 1 +
 src/include/nodes/relation.h         | 7 ++++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/backend/optimizer/util/plancat.c 
index cac46bedf9..1273f28069 100644
--- a/src/backend/optimizer/util/plancat.c
+++ b/src/backend/optimizer/util/plancat.c
@@ -1897,6 +1897,7 @@ find_partition_scheme(PlannerInfo *root, Relation 
        part_scheme->partopfamily = partkey->partopfamily;
        part_scheme->partopcintype = partkey->partopcintype;
        part_scheme->parttypcoll = partkey->parttypcoll;
+       part_scheme->partcollation = partkey->partcollation;
        part_scheme->parttyplen = partkey->parttyplen;
        part_scheme->parttypbyval = partkey->parttypbyval;
diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h
index 48e6012f7f..2adefd0873 100644
--- a/src/include/nodes/relation.h
+++ b/src/include/nodes/relation.h
@@ -342,6 +342,10 @@ typedef struct PlannerInfo
  * partition bounds. Since partition key data types and the opclass declared
  * input data types are expected to be binary compatible (per ResolveOpClass),
  * both of those should have same byval and length properties.
+ *
+ * Since partitioning might be using a collation for a given partition key
+ * column that is not same as the collation implied by column's type, store
+ * the same separately.
 typedef struct PartitionSchemeData
@@ -349,7 +353,8 @@ typedef struct PartitionSchemeData
        int16           partnatts;              /* number of partition 
attributes */
        Oid                *partopfamily;       /* OIDs of operator families */
        Oid                *partopcintype;      /* OIDs of opclass declared 
input data types */
-       Oid                *parttypcoll;        /* OIDs of collations of 
partition keys. */
+       Oid                *parttypcoll;        /* OIDs of partition key type 
collation. */
+       Oid                *partcollation;      /* OIDs of partitioning 
collation */
        /* Cached information about partition key data types. */
        int16      *parttyplen;

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to