Re: contrib/pg_stat_statements 1202

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, "Vladimir Sitnikov" <sitnikov(dot)vladimir(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib/pg_stat_statements 1202
Date: 2008-12-09 16:35:04
Message-ID: 603c8f070812090835l3d800550gb249e21d67220704@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-09 16:43:26 Re: Multiplexing SUGUSR1
Previous Message Andrew Dunstan 2008-12-09 16:34:06 Re: parallel restore vs. windows