Re: contrib/pg_stat_statements 1202

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: contrib/pg_stat_statements 1202
Дата
Msg-id 1d709ecc0812041632u512d8a9cq641cd14eaa0e85c1@mail.gmail.com
обсуждение исходный текст
Ответ на Re: contrib/pg_stat_statements 1202  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: contrib/pg_stat_statements 1202  (Greg Smith <gsmith@gregsmith.com>)
Список pgsql-hackers
"Vladimir Sitnikov" <sitnikov.vladimir@gmail.com> writes:

> I wish there was a way to get the results of explain into some table. I wish
> it was the default output "format". That would make life of pgAdmin easier,
> and improve readability even in psql. Do not you think there is something
> wrong with having "cost=... rows=... loops=..." in each and every row?

A number of people have suggesting we switch to XML.
I do not see much benefit of XML:
 * XML is not human-readable
 * Plain old result set is even easier to process since it is the main PostgreSQL interface at this point

The only benefit of XML I could imagine is it could provide a nicer markup for sort/hash/etc nodes. It is not that nice to have a column "sort method" that would be empty nearly for all the rows. At the same time it looks fine to have a column with xml inside for any additional information execution node wants provide (like topN-allrows sort / number of batches in hash join or whatever)
 

An alternative would be to build up a tuplestore of data and then send that to
the client in a separate result set. That's kind of nice because it would give
us a way to send both the real results and the explain results. And at least
we already have an api for accessing result sets.
Sounds good. As for me, current output of explain is not very easy to read: it suits well only for "find timings for particular node" workflow only (I mean, the source is a particular node, the result is timings/rows/buffers/etc). However from my point of view, when it comes to query tuning the main workflow is "find node by suspicious timings". If all the relevant data were displayed in the same column it would be easier to read. Consider all the row counts in the very first column.


Oracle's approach is to have the explain command stuff the results into a
table. That has advantages for tools, especially if you want to be able to
look at plans generated by other sessions.
I do not believe that workflow makes sense. I have never ever thought of it.

External table makes sense if you have several output formats (say, create a formatting function for psql and let pgAdmin format the plan on its own)
 
Regards,
Vladimir Sitnikov

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

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: In-place upgrade: catalog side
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Simple postgresql.conf wizard