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

On Mon, Nov 12, 2018 at 10:55 AM Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
>
> On Fri, Nov 9, 2018 at 2:12 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> On Thu, Nov 8, 2018 at 10:56 PM Magnus Hagander <magnus@hagander.net> wrote:
>> >
>> > On Thu, Nov 8, 2018 at 3:53 PM Sergei Kornilov <sk@zsrv.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
stillthink 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?
>
>
> I thought that returning the affected number of statements with the change
> of adding new parameters to the reset function will be helpful to find out
> how many statements are affected?
>

It is not clear how will user make use of that information.

> I can revert it back to void,
>

+1, as we don't see any good reason to break backward compatibility.

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