Re: [HACKERS] path toward faster partition pruning

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.

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.

Thanks,

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company