Re: contrib/pg_stat_statements 1202 - Mailing list pgsql-hackers

From Vladimir Sitnikov
Subject Re: contrib/pg_stat_statements 1202
Date
Msg-id 1d709ecc0812041632u512d8a9cq641cd14eaa0e85c1@mail.gmail.com
Whole thread Raw
In response to Re: contrib/pg_stat_statements 1202  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: contrib/pg_stat_statements 1202  (Greg Smith <gsmith@gregsmith.com>)
List 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 by date:

Previous
From: Gregory Stark
Date:
Subject: Re: In-place upgrade: catalog side
Next
From: Josh Berkus
Date:
Subject: Re: Simple postgresql.conf wizard