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 711b1f71-1adc-b67e-1f36-631c8defad25@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] path toward faster partition pruning  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 2017/11/30 7:15, Robert Haas wrote:
> On Wed, Nov 29, 2017 at 3:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote
>> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>>> It seems I wrote an Assert in the code to support hash partitioning that
>>> wasn't based on a valid assumption.  I was wrongly assuming that all hash
>>> partitions for a given modulus (largest modulus) must exist at any given
>>> time, but that isn't the case.
>>
>> Committed 0003 with some adjustments:
>>
>> * Renamed the new test to partition_prune.
>> * Moved the test to what I thought was a better place in the schedule
>> file, and made it consistent between serial_schedule and
>> parallel_schedule.
>> * commutates -> commuted
>> * removed wrong /* empty */ comment
>> * Updated expected output.  It surprised me a bit that the tests
>> weren't passing as you had them, but the differences I got - all
>> related to mc3p_default - seemed correct to me
> 
> Committed 0004 after reviewing the code and testing that it seems to
> work as advertised.

Thank you.

> 0005 looks like it might need to be split into smaller patches.  More
> broadly, the commit messages you wrote for for 0005, 0006, and 0008
> don't seem to me to do a great job explaining the motivation for the
> changes which they make.  They tell me what the patches do, but not
> why they are doing it.  If there's an email in this thread that
> explains that stuff, please point me to it and I'll go back and reread
> it more carefully; if not, I think I definitely need some more
> explanation both of the mission of each patch and the reason why the
> patch set is divided up in the way that it is.

I'm working on a revised version of these patches to address recent
comments by Horiguchi-san.  I will also consider the points above before
sending the new version.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] SERIALIZABLE with parallel query