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

Поиск
Список
Период
Сортировка
От Sergei Kornilov
Тема Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query
Дата
Msg-id 84928391541688759@myt4-174696c9aa9d.qloud-c.yandex.net
обсуждение исходный текст
Ответ на Re: New function pg_stat_statements_reset_query() to resetstatistics of a specific query  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query  (Magnus Hagander <magnus@hagander.net>)
Список 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
thinkLOG ereport is not useful.
 

regards, Sergei


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: [HACKERS] Surjective functional indexes
Следующее
От: Pavel Stehule
Дата:
Сообщение: proposal: variadic argument support for least, greatest function