=?gb2312?B?amFzb255c2xpKMDu1L7JrSk=?= <jasony...@tencent.com> writes:
> Yes, it seems the pg_stat_sql function can fit the individual need of
> collecting tags of query. However the new function can not return other
> values of query at the same time, such as block number info, run time and so
> on. Returning these values at the same time are very important.
Meh ... that seems like a justification that was made up on the fly,
rather than being a demonstrable requirement. What's the specific use
case that requires it?
After thinking about this some more I'm really pretty dubious that storing
the command tag will get you anything you can't get as well or better by
looking at the first word or two of the query text. I don't believe the
original claim that doing so is "too expensive for a monitoring system".
It does not take that much to pull out a couple of whitespace-separated
keywords and perhaps case-fold them, and by the time you've fetched the
string out of the database you've spent way more cycles than that.
A slightly better argument is that WITH will confuse matters, but really
it does anyway: consider
WITH x AS (INSERT INTO ... RETURNING *)
SELECT * FROM x;
This will get a command tag of "SELECT", but any reasonable person would
deem that this would be better characterized as an INSERT. So I think
if you want useful results for WITH cases you're going to need to spend
effort looking at the querystring anyway.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
