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

On Thu, Nov 8, 2018 at 10:56 PM Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
> On Thu, Nov 8, 2018 at 3:53 PM Sergei Kornilov <sk(at)zsrv(dot)org> wrote:
>>
>> 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.
>
>
> I would much prefer it to be a return code rather than a forced LOG message. Log message spam is very much a thing, and things that are logged as LOG will always be there.
>

Is any such LOG message present in the latest patch? I agree that the
return code might be better, but there doesn't exist any such (LOG)
thing. I see that it can be helpful for some users if we have any
such return code, but don't know if it doesn't already exist, why that
should be a requirement for this patch? Do you have any strong
opinion about introducing return code with this patch?

> It could also be made to take a parameter saying log yes/no with a default value, but that seems like possible overengineering of a fairly simple functionality.
>

Right.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com