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?
Re: Open Item: Should non-text EXPLAIN always show properties? |
Список | 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 по дате отправления: