Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)
Дата
Msg-id CAApHDvrzdwJP4ymQNe7Zq1Mux4kbT_gc+RPkezgF9TtA158EYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
On Tue, Oct 14, 2014 at 6:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andres Freund <andres@2ndquadrant.com> writes:
> Well. Unless I miss something it doesn't resolve the problem that
> started this thread. Namely that it's currently impossible to write
> regression using EXPLAIN (ANALYZE, TIMING OFF. COSTS OFF). Which is
> worthwhile because it allows to tests some behaviour that's only visible
> in actually executed plans (like seing that a subtree wasn't executed).

TBH, I don't particularly care about that.  A new flag for turning
"summary timing" off would answer the complaint with not too much
non-orthogonality ... but I really don't find this use case compelling
enough to justify adding a feature to EXPLAIN.


Hmm, was my case above not compelling enough? 
This leaves me out in the cold a bit for when it comes to testing inner joins are properly skipped at execution time. I can see no other way to properly verify when the joins are and are not being skipped other than outputting the explain analyze in the test and I can't really imagine it ever getting committed without proper regression tests.

Can you think of some other way that I could test this? Keep in mind there's no trace of the removal in the EXPLAIN without ANALYZE.

Regards

David Rowley


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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Typo in bgworker.sgml
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [9.4 bug] The database server hangs with write-heavy workload on Windows