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
partition_rbound_datum_cmp:
cmpval = DatumGetInt32(FunctionCall2Coll(&key->partsupfunc[i],
key->partcollation[i],
rb_datums[i],
tuple_datums[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.
Thoughts?
Thanks,
Amit
[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
b/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
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;
--
2.11.0
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
