Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query
От | Haribabu Kommi |
---|---|
Тема | Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query |
Дата | |
Msg-id | CAJrrPGfpYka97iES5guHHzEYSW_A3FSd1azTo9dZ3JEqKvwy3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query
Re: New function pg_stat_statements_reset_query() to resetstatistics of a specific query |
Список | pgsql-hackers |
On Tue, Nov 20, 2018 at 2:06 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Mon, Nov 19, 2018 at 10:48 AM Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
> On Mon, Nov 19, 2018 at 1:37 PM Alvaro Herrera <alvherre@2ndquadrant.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.
>
> 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.
>
Hmm, can we use 0 as default value without any such caveat?
Yes, with strict and 0 as default value can work.
If there is no problem, I can go ahead with the above changes?
Regards,
Haribabu Kommi
Fujitsu Australia
В списке pgsql-hackers по дате отправления: