Re: [GENERAL] Performance of full outer join in 8.3 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Performance of full outer join in 8.3
Date
Msg-id 3010.1239838791@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] Performance of full outer join in 8.3  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [GENERAL] Performance of full outer join in 8.3  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> We could add some regression tests that create a sample data set,
> ANALYZE it, and then EXPLAIN various things.  The results should be
> deterministic,

Sorry, you're wrong.

The output of EXPLAIN is nowhere near stable enough to use within the
current exact-match regression test framework.  I'm not sure it would
be stable even if we suppressed the rowcount and cost figures.  Those
figures vary across platforms (because of alignment effects and probably
other things) and are also sensitive to the timing of autovacuums.  It
is known that a nontrivial fraction of the existing regression test
cases do suffer from uninteresting plan changes across platforms or
as a result of various phase-of-the-moon effects; that's why we keep
having to add "ORDER BY" clauses now and then.

The other problem with any large set of such tests is that any time you
intentionally change the optimizer, a great deal of careful analysis
would be needed to determine if the resulting EXPLAIN changes were good,
bad, or indifferent; not to mention whether the change *should* have
changed some plans that did not change.

There might be net value in maintaining such a test suite, but it would
be a lot of work with no certain benefit, and I don't see anyone
stepping up to do it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [GENERAL] Performance of full outer join in 8.3
Next
From: Bruce Momjian
Date:
Subject: Re: libpq is not thread safe