Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11
Дата
Msg-id 10739.1562613701@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11  (Michael Paquier <michael@paquier.xyz>)
Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11  (Melanie Plageman <melanieplageman@gmail.com>)
Список pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> Well, another thing I'd like to think about is if there is any point
> to keep regressplans.sh and the relevant options in postgres at this
> stage.  From the top of the file one can read that:

The point of regressplans.sh is to see if anything goes seriously
wrong when forcing non-default plan choices --- seriously wrong being
defined as crashes or semantically wrong answers.  It's not expected
that the regression tests will automatically pass when you do that,
because of their dependencies on output row ordering, not to mention
all the EXPLAINs.  I'm not for removing it --- the fact that its
results require manual evaluation doesn't make it useless.

Having said that, join_hash.sql in particular seems to have zero
value if it's not testing hash joins, so I think it'd be reasonable
for it to override a global enable_hashjoin = off setting.  None of
the other regression test scripts seem to take nearly as much of a
performance hit from globally forcing poor plans.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: tableam: abstracting relation sizing code
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)