Re: [HACKERS] path toward faster partition pruning

On 2017/11/30 7:15, Robert Haas wrote:
> On Wed, Nov 29, 2017 at 3:28 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote
>> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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