Horton

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

Sergei Kornilov <sk@zsrv.org>

View thread View on postgr.es
From: Sergei Kornilov <sk@zsrv.org>
To: Alvaro Herrera <alvherre@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>
Cc: Haribabu Kommi <kommi.haribabu@gmail.com>, Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, Euler Taveira <euler@timbira.com.br>, pgsql-hackers <pgsql-hackers@postgresql.org>, Simon Riggs <simon@2ndquadrant.com>, Dave Page <dpage@pgadmin.org>
Date: 2018-11-08T14:52:39Z
Lists: pgsql-hackers 
Hi

>>  Sure, but what are we going to achieve with that number? What
>>  information user is going to get by that? If it can help us to ensure
>>  that it has reset the expected number of statements, then I can see
>>  the clear usage, but without that, the return value doesn't seem to
>>  have any clear purpose. So, I don't see much value in breaking
>>  compatibility.
>>
>>  Does anyone else have an opinion on this matter?
>
> This was proposed by Sergei Kornilov in
> https://postgr.es/m/3368121530260059@web21g.yandex.ru saying that "it
> would be nice" to return it. Maybe he has an use case in mind? I don't
> see one myself.
No, i have no specific usecase for this. Silently remove all matching rows and return void is ok for me. But i still think LOG ereport is not useful.

regards, Sergei

Commits

  1. Extend pg_stat_statements_reset to reset statistics specific to a

  2. Default monitoring roles