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

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, 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>, Pg 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-19 05:18:02
Message-ID: CAJrrPGcG9bO9PDyWsh3F=qdOYUTxuzd2FcvQLkqL5Djmv-au8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

I prefer single API. I can go with either 3 or 4.

opinion from others?

Regards,
Haribabu Kommi
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Lepikhov 2018-11-19 05:48:06 Re: [PATCH] XLogReadRecord returns pointer to currently read page
Previous Message Amit Kapila 2018-11-19 05:06:02 Re: WIP: Avoid creation of the free space map for small tables