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

From Robert Haas
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id CA+TgmoZj7cMUG690q9bts4J+JUXApxpFPXMvvL1S0QGWEKRG0w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [HACKERS] path toward faster partition pruning
Re: [HACKERS] path toward faster partition pruning
List pgsql-hackers
On Wed, Apr 11, 2018 at 8:35 AM, Alvaro Herrera <alvherre@alvh.no-ip.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.

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


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: WIP: Covering + unique indexes.
Next
From: Tom Lane
Date:
Subject: Instability in the postgres_fdw regression test