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

From Greg Stark
Subject Re: contrib/pg_stat_statements 1202
Date
Msg-id EBE2E804-23D5-4862-AFE8-15AE2EA81AD7@enterprisedb.com
Whole thread Raw
In response to Re: contrib/pg_stat_statements 1202  ("Robert Haas" <robertmhaas@gmail.com>)
Responses Re: contrib/pg_stat_statements 1202
List pgsql-hackers
Yes this is one reasonable option, as is the idea of using XML or a  
table and making it the client's problem. Neither are going to happen  
for this release I think.

And in any case it will always be useful to have an option to print  
all the available information anyways so we make as well do that with  
"verbose".


-- 
Greg


On 9 Dec 2008, at 16:35, "Robert Haas" <robertmhaas@gmail.com> wrote:

>> As stuff matures and becomes indispensable we could consider moving  
>> it to the
>> regular EXPLAIN or implement some way to specify precisely which  
>> data the user
>> wants. Or just say XML/table data/whatever will solve the problem  
>> for us.
>
> I think some way to specify precisely which data the user wants is the
> way to go.  The amount of data that there is to be printed is only
> going to continue to increase.  If the only toggle is a boolean flag
> to display ALL or NONE of it, then every time someone proposes a new
> type of output, we're going to argue about whether it's useful enough
> to be worth the display real estate.
>
> I'm not sure what the best way is though.  I don't think continuing to
> add keywords between EXPLAIN and the start of the query is very
> scalable.  Putting parentheses around the option list seems like it
> might eliminate a lot of grammar headaches:
>
> EXPLAIN (option, option, option...) SELECT ...
>
> ...Robert


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: parallel restore vs. windows
Next
From: Andrew Chernow
Date:
Subject: Re: parallel restore vs. windows