From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Robert Haas <rhaas(at)postgresql(dot)org>, pgsql-committers(at)postgresql(dot)org, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] PartitionSchemaData & partcollation (Re: pgsql: Associate partitioning information with each RelOptInfo.) |
Date: | 2017-09-28 07:20:39 |
Message-ID: | 7cec02e2-91cf-40e0-7ed8-e3ba18f62a2c@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-09-28 12:21:37 | Re: pgsql: Add test for postmaster crash restarts. |
Previous Message | Ashutosh Bapat | 2017-09-28 07:13:58 | Re: [HACKERS] PartitionSchemaData & partcollation (Re: pgsql: Associate partitioning information with each RelOptInfo.) |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-09-28 08:14:56 | Re: path toward faster partition pruning |
Previous Message | Ashutosh Bapat | 2017-09-28 07:13:58 | Re: [HACKERS] PartitionSchemaData & partcollation (Re: pgsql: Associate partitioning information with each RelOptInfo.) |