pgsql: Associate partitioning information with each RelOptInfo.
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.
Discussion: /messages/by-id/CAFjFpRfneFG3H+F6BaiXemMrKF+FY-POpx3Ocy+RiH3yBmXSNw@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/9140cf8269b0c4ae002b2748d93979d535891311
Modified Files
--------------
src/backend/optimizer/util/plancat.c | 159 +++++++++++++++++++++++++++++++++++
src/backend/optimizer/util/relnode.c | 37 +++++++-
src/include/nodes/relation.h | 56 +++++++++++-
3 files changed, 249 insertions(+), 3 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
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]https://commitfest.postgresql.org/14/1272/, but thought we could independently
fix this.
Thoughts?
Thanks,
Amit
Attachments:
0001-Add-partcollation-field-to-PartitionSchemeData-v1.patchtext/plain; charset=UTF-8; name=0001-Add-partcollation-field-to-PartitionSchemeData-v1.patchDownload
From 4e25d503a00c5fb42919e73aae037eacb0164af6 Mon Sep 17 00:00:00 2001
From: amit <amitlangote09@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
Sorry, I meant to say PartitionSchem"e"Data in subject.
Thanks,
Amit
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Thu, Sep 28, 2017 at 11:47 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
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.
I think PartitionSchemeData structure will grow as we need more
information about partition key for various things. E.g. partsupfunc
is not part of this structure right now, but it would be required to
compare partition bound datums. Similarly partcollation. Please add
this to partition pruning patchset. May be parttypcoll won't be used
at all and we may want to remove it altogether.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On 2017/09/28 16:13, Ashutosh Bapat wrote:
On Thu, Sep 28, 2017 at 11:47 AM, Amit Langote wrote:
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.I think PartitionSchemeData structure will grow as we need more
information about partition key for various things. E.g. partsupfunc
is not part of this structure right now, but it would be required to
compare partition bound datums. Similarly partcollation. Please add
this to partition pruning patchset. May be parttypcoll won't be used
at all and we may want to remove it altogether.
Okay, I will post it with the partition-pruning patch set.
Thanks,
Amit
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers