Re: Open Item: Should non-text EXPLAIN always show properties?

Поиск
Список
Период
Сортировка
От James Coleman
Тема Re: Open Item: Should non-text EXPLAIN always show properties?
Дата
Msg-id CAAaqYe_qZtt1DWTReSJLU-+itgpnVK+MbBTDRmMW5ByorhnYpQ@mail.gmail.com
обсуждение исходный текст
Ответ на Open Item: Should non-text EXPLAIN always show properties?  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Open Item: Should non-text EXPLAIN always show properties?  (Robert Haas <robertmhaas@gmail.com>)
Re: Open Item: Should non-text EXPLAIN always show properties?  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On Thu, Jun 25, 2020 at 5:15 AM David Rowley <dgrowleyml@gmail.com> wrote:
>
> Over on [1] Justin mentions that the non-text EXPLAIN ANALYZE should
> always show the "Disk Usage" and "HashAgg Batches" properties.  I
> agree with this. show_wal_usage() is a good example of how we normally
> do things.  We try to keep the text format as humanly readable as
> possible but don't really expect humans to be commonly reading the
> other supported formats, so we care less about including additional
> details there.
>
> There's also an open item regarding this for Incremental Sort, so I've
> CC'd James and Tomas here. This seems like a good place to discuss
> both.

Yesterday I'd replied [1] to Justin's proposal for this WRT
incremental sort and expressed my opinion that including both
unnecessarily (i.e., including disk when an in-memory sort was used)
is undesirable and confusing and leads to shortcuts I believe to be
bad habits when using the data programmatically.

On a somewhat related note, memory can be 0 but that doesn't mean no
memory was used: it's a result of how tuplesort.c doesn't properly
track memory usage when it switches to disk sort. The same isn't true
in reverse (we don't have 0 disk when disk was used), but I do think
it does show the idea that showing "empty" data isn't an inherent
good.

If there's a clear established pattern and/or most others seem to
prefer Justin's proposed approach, then I'm not going to fight it
hard. I just don't think it's the best approach.

James

[1] https://www.postgresql.org/message-id/CAAaqYe-LswZFUL4k5Dr6%3DEN6MJG1HurggcH4QzUs6UFqBbnQzQ%40mail.gmail.com



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: More tzdb fun: POSIXRULES is being deprecated upstream