On Wed, Feb 28, 2018 at 6:42 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2018/02/28 1:05, Robert Haas wrote:
>> On Mon, Feb 26, 2018 at 10:59 PM, Amit Langote
>> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>>> You may say that partition bounds might have to be different too in this
>>> case and hence partition-wise join won't occur anyway, but I'm wondering
>>> if the mismatch of partcollation itself isn't enough to conclude that?
>>
>> Yeah, you're right. I think that this is just a bug in partition-wise
>> join, and that the partition scheme should just be using partcollation
>> instead of parttypcoll, as in the attached.
>
> Ah, OK. I was missing that there is no need to have both parttypcoll and
> partcollation in PartitionSchemeData, as the Vars in rel->partexprs are
> built from a bare PartitionKey (not PartitionSchemeData), and after that
> point, parttypcoll no longer needs to kept around.
Yes. That's right.
>
> I noticed that there is a typo in the patch.
>
> + memcpy(part_scheme->partcollation, partkey->parttypcoll,
>
> s/parttypcoll/partcollation/g
>
> BTW, should there be a relevant test in partition_join.sql? If yes,
> attached a patch (partitionwise-join-collation-test-1.patch) to add one.
A partition-wise join path will be created but discarded because of
higher cost. This test won't see it in that case. So, please add some
data like other tests and add command to analyze the partitioned
tables. That kind of protects from something like that.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company