Re: [HACKERS] path toward faster partition pruning - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id f74675dc-e7f0-a7a0-7255-1c8f4bb8b339@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2018/03/01 2:23, Robert Haas wrote:
> On Tue, Feb 27, 2018 at 8:12 PM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> 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.
>>
>> I noticed that there is a typo in the patch.
>>
>> +       memcpy(part_scheme->partcollation, partkey->parttypcoll,
>>
>> s/parttypcoll/partcollation/g
> 
> Committed your version.

Thank you.

>> 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.
> 
> I don't feel strongly about it, but I'm not going to try to prevent
> you from adding one, either.

OK.  Attached is a revised version of that patch in case you consider
committing it, addressing Ashutosh's comment that the tables used in the
test should contain some data.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [bug fix] pg_rewind creates corrupt WAL files, and the standbycannot catch up the primary
Next
From: Peter Eisentraut
Date:
Subject: faster testing with symlink installs