Re: New EXPLAIN option: ALL

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: New EXPLAIN option: ALL
Дата
Msg-id 20190515175806.qciblz6rhi4rzu6y@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: New EXPLAIN option: ALL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: New EXPLAIN option: ALL  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Hi,

On 2019-05-15 13:53:26 -0400, Tom Lane wrote:
> FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name",
> we should probably just drop the whole idea.  It seemed like a great
> idea at the time, but it's going to confuse people not just Bison.

I'm not particularly invested in the idea of renaming ANALYZE - but I
think we might be able to come up with something less ambiguous than
EXECUTE. Even EXECUTION might be better.


> So ... never mind that suggestion.  Can we get anywhere with the
> rest of it?

Yes, please. I still think getting rid of

    if (es->buffers && !es->analyze)
        ereport(ERROR,
                (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                 errmsg("EXPLAIN option BUFFERS requires ANALYZE")));
and
    /* check that timing is used with EXPLAIN ANALYZE */
    if (es->timing && !es->analyze)
        ereport(ERROR,
                (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                 errmsg("EXPLAIN option TIMING requires ANALYZE")));

and then changing the default for BUFFERs would be good. I assume they'd
still only apply to query execution.

Althouh, in the case of BUFFERS, I more than once wished we'd track the
plan-time stats for buffers as well. But that's a significantly more
complicated change.

Greetings,

Andres Freund



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: New EXPLAIN option: ALL
Следующее
От: Alvaro Herrera
Дата:
Сообщение: more message fixes