Re: Resetting a single statistics counter - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Resetting a single statistics counter
Date
Msg-id 9837222c1001241021o2d7a22cap6d818944913ede22@mail.gmail.com
Whole thread Raw
In response to Re: Resetting a single statistics counter  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Resetting a single statistics counter  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2010/1/24 Tom Lane <tgl@sss.pgh.pa.us>:
> Euler Taveira de Oliveira <euler@timbira.com> writes:
>> Magnus Hagander escreveu:
>>> Off to make it two separate functions.. (seems much more user-friendly
>>> than a single function with an extra argument, IMHO)
>
>> +1. But as Simon said _single_ is too ugly. What about
>> pg_stat_reset_user_{function,relation}?
>
> That implies that the operations wouldn't work against system tables;
> which they do.  I think a bigger problem is that "reset_single_table"
> seems like it might be talking about something like a TRUNCATE, ie,
> it's not clear that it means to reset counters rather than data.
> The pg_stat_ prefix is some help but not enough IMO.  So I suggest
> pg_stat_reset_table_counters and pg_stat_reset_function_counters.

Doesn't the pg_stat_ part already say this?


> (BTW, a similar complaint could be made about the previously committed
> patch: reset shared what?)

Well, it could also be made about the original pg_stat_reset()
function - reset what?


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: commit fests
Next
From: Tom Lane
Date:
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns