Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11
Date
Msg-id 10739.1562613701@sss.pgh.pa.us
Whole thread Raw
In response to Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11  (Michael Paquier <michael@paquier.xyz>)
Responses 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>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: tableam: abstracting relation sizing code
Next
From: Tomas Vondra
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)