=?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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers