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

From Robert Haas
Subject Re: contrib/pg_stat_statements 1202
Date
Msg-id 603c8f070812090835l3d800550gb249e21d67220704@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  ("Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>)
Re: contrib/pg_stat_statements 1202  (Greg Stark <greg.stark@enterprisedb.com>)
List pgsql-hackers
> 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: Tom Lane
Date:
Subject: Re: Multiplexing SUGUSR1