Re: [HACKERS] path toward faster partition pruning
От | David Rowley |
---|---|
Тема | Re: [HACKERS] path toward faster partition pruning |
Дата | |
Msg-id | CAKJS1f9EoepeCamvnu285qZSHLfAtgHDqGrVkOY5357thKAkkQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] path toward faster partition pruning (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On 13 April 2018 at 14:15, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > On 2018/04/13 1:47, Robert Haas wrote: >> 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. > > Do you mean to do that for *all* files that have tests exercising some > partitioning code, even if it's just one test? I can see that tests in at > least some of them could be put into their own partition_ file as follows: Wouldn't it be best to just move hash partition tests into hash_part? Leave all the other stuff where it is? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: