Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query
| От | Magnus Hagander |
|---|---|
| Тема | Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query |
| Дата | |
| Msg-id | CABUevEzhcennJPdOB43VKD421LWDFo4Gzs=E3f8FgbcCR3u=Sg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query (Sergei Kornilov <sk@zsrv.org>) |
| Ответы |
Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query
|
| Список | pgsql-hackers |
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 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.
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.
В списке pgsql-hackers по дате отправления: