Re: [GENERAL] Performance of full outer join in 8.3

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] Performance of full outer join in 8.3
Дата
Msg-id 3010.1239838791@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] Performance of full outer join in 8.3  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [GENERAL] Performance of full outer join in 8.3  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [GENERAL] Performance of full outer join in 8.3
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: libpq is not thread safe