Re: [HACKERS] PartitionSchemaData & partcollation (Re: pgsql: Associate partitioning information with each RelOptInfo.)

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

In response to

Browse pgsql-committers by date

  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.)

Browse pgsql-hackers by date

  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.)