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: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Magnus Hagander <magnus(at)hagander(dot)net>, 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-22 03:09:54
Message-ID: CAA4eK1Ktd8QuU__B-vMtdLL85t+prZ=QrrPPAKqX5YiurzoOzQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 19, 2018 at 10:48 AM Haribabu Kommi
<kommi(dot)haribabu(at)gmail(dot)com> wrote:
>
> On Mon, Nov 19, 2018 at 1:37 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>>
>> On 2018-Nov-19, Michael Paquier wrote:
>>
>> > On Mon, Nov 19, 2018 at 10:41:22AM +1100, Haribabu Kommi wrote:
>> > > So 6 new functions needs to be added to cover all the above cases,
>> > > IMO, we may need functions for all combinations, because I feel some
>> > > user may have the requirement of left out combination, in case if we choose
>> > > only some combinations.
>> >
>> > That's bloating the interface in my opinion.
>>
>> I understand.
>>
>> Let's call for a vote from a larger audience. It's important to get
>> this interface right, ISTM.
>
>
> Amit suggested another option in another mail, so total viable
> solutions that are discussed as of now are,
>
> 1. Single API with NULL input treat as invalid value
> 2. Multiple API to deal with NULL input of other values
> 3. Single API with NULL value to treat them as current user, current database
> and NULL queryid.
> 4. Single API with -1 as invalid value, treat NULL as no matching. (Only problem
> with this approach is till now -1 is also a valid queryid, but setting -1 as queryid
> needs to be avoided.
>

As discussed above the problem mentioned by Hari in point-4 won't be
there if we use a default value as 0.

> I prefer single API. I can go with either 3 or 4.
>
> opinion from others?

We don't see many opinions from others, but what I can read here is the count:
Option-3: Michael, Hari
Option-4: Amit, Hari
Option-2: Alvaro

As Hari seems to be a bit more inclined towards option-4, I think we
can proceed with it.

Alvaro, we understand your concerns and it seems there is some genuine
way to address that. Kindly let us know if you still see the issue or
you are still not comfortable? If you are not comfortable with what
is being proposed, kindly suggest a way forward for this patch?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-11-22 03:34:40 Re: incorrect xlog.c coverage report
Previous Message Alvaro Herrera 2018-11-22 02:45:01 Re: incorrect xlog.c coverage report