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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, sk(at)zsrv(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>
Subject: Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query
Date: 2018-11-08 09:45:29
Message-ID: CAA4eK1J8z2aEoSyd+_V1w+a+2XZgmmYRjGKXeHswEMK16oi_OA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 8, 2018 at 1:52 PM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> wrote:
> On Thu, Nov 8, 2018 at 4:53 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> > This patch has changed the pg_stat_statements_reset() function from returning void
>> > to number statements that it reset.
>> >
>>
>> What is the motivation of that change? It seems to be
>> backward-incompatible change. I am not telling we can't do it, but do
>> we have strong justification? One reason, I could see is to allow the
>> user to get the exact value of statements that got reset and maybe
>> that is more helpful as we have now additional parameters in the API,
>> but I am not sure if that is a good justification.
>
>
> Yes, as you said that is the main reason to modify the function to return
> the number of statements that it reset. Without having any output from
> the function, there is no way that how many statements that the above
> function reset. Earlier it used to reset every statement, so I feel there is
> no need of any output, but I feel giving the number of statements with
> this approach is good.
>

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?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-11-08 09:46:56 Re: PostgreSQL Limits and lack of documentation about them.
Previous Message Masahiko Sawada 2018-11-08 09:32:51 Re: New vacuum option to do only freezing