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.  
So I think it is still needed by pg_stat_statement when monitoring a database 
发件人: [] 代表 
Tsunakawa, Takayuki []
发送时间: 2017年2月20日 8:34
收件人: ''; pgsql-hackers
主题: Re: [HACKERS] Adding new output parameter of pg_stat_statements toidentify 
operation of the query.(Internet mail)

> [] On Behalf Of
>          When using pg_stat_statements to collect running SQL of PG, we
> find it is hard for our program to get exact operation type of the SQL,
> such as SELECT, DELETE, UPDATE, INSERT, and so on.
>    So we modify the the source code of pg_stat_statements and add another
> output parameter to tell us the operation type.
> Of course some application know their operation type, but for us and many
> public databases, doing this is hard.
> The only way is to reparse the SQL, obviously it is too expensive for a
> monitoring or diagnosis system.
> We have done the job and are willing to post a patch.
> I sent one through my work mail, but it seems that my mail didn't reach
> the maillist, so I try again by using my personal mail account.

A view for counting the number of executions per operation type is being 
developed for PostgreSQL 10, which is expected to be released this year.

Would this fit your need?  If not, what's the benefit of getting the operation 
type via pg_stat_statements?

Takayuki Tsunakawa

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to