Re: [HACKERS] path toward faster partition pruning

On Fri, Apr 13, 2018 at 10:50 AM, Alvaro Herrera
<alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Robert Haas wrote:
>> On Wed, Apr 11, 2018 at 8:35 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> > Here's an idea. Why don't we move the function/opclass creation lines
>> > to insert.sql, without the DROPs, and use the same functions/opclasses
>> > in the three tests insert.sql, alter_table.sql, hash_part.sql and
>> > partition_prune.sql, i.e. not recreate what are essentially the same
>> > objects three times? This also leaves them around for the pg_upgrade
>> > test, which is not a bad thing.
>>
>> That sounds good, but maybe we should go further and move the
>> partitioning tests out of generically-named things like insert.sql
>> altogether and have test names that actually mention partitioning.
>
> I don't think that's necessary to fix the problem that
> partition_prune_hash.sql file has two expected output files. If you
> want to propose such a reorganization, feel free, but let's not hijack
> the patch at hand. For the record, I'm not a fan of the idea.

Fair enough. I don't think I'm hacking the thread much more than it
was already hijacked; and it was just a thought. I haven't really
studied the tests well enough to have a really clear idea what a
better organization would look like. It was just that, for example,
the commit that added hash partitioning added tests to 5 different
files, and some things had to be duplicated as a result. It sounds
like what you've already done improves that, but I was wondering if
there's a way to do better. I don't feel super-strongly about it
though.

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