Re: New EXPLAIN option: ALL

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: New EXPLAIN option: ALL
Дата
Msg-id 20190507215449.3a4yb5kkoloq7yyw@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: New EXPLAIN option: ALL  (David Fetter <david@fetter.org>)
Ответы Re: New EXPLAIN option: ALL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2019-05-07 23:23:55 +0200, David Fetter wrote:
> Would you agree that there's a problem here as I described as
> motivation for people who operate databases?

Yea, but I don't think the solution is where you seek it.  I think the
problem is that our defaults for EXPLAIN, in particular EXPLAIN ANALYZE,
are dumb. And that your desire for ALL stems from that, rather than it
being desirable on its own.

We really e.g. should just enable BUFFERS by default. The reason we
can't is that right now we have checks like:
EXPLAIN (BUFFERS) SELECT 1;
ERROR:  22023: EXPLAIN option BUFFERS requires ANALYZE
LOCATION:  ExplainQuery, explain.c:206

but we ought to simply remove them. There's no benefit, and besides
preventing from enabling BUFFERS by default it means that
enabling/disabling ANALYZE is more work than necessary.


> If so, do you have one or more abbreviations in mind that aren't
> called ALL? I realize that Naming Things™ is one of two hard problems
> in computer science, but it's still one we have to tackle.

As I said, I don't think ALL is a good idea under any name.  Like it
just makes no sense to have ANALYZE, SUMMARY, VERBOSE, BUFFERS,
SETTINGS, FORMAT controlled by one option, unless you call it DWIM. It's
several separate axis (query is executed or not (ANALYZE), verbosity
(SUMMARY, VERBOSE), collecting additional information (BUFFERS, TIMING),
output format).

Greetings,

Andres Freund



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: make \d pg_toast.foo show its indices
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: make \d pg_toast.foo show its indices