2010/1/24 Euler Taveira de Oliveira :
> Tom Lane escreveu:
>> 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
Tom Lane escreveu:
> 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.
2010/1/24 Tom Lane :
> Magnus Hagander writes:
>> 2010/1/24 Tom Lane :
>>> 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?
>
> My objection is that "reset_table
Magnus Hagander writes:
> 2010/1/24 Tom Lane :
>> 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?
My objection is that "reset_table" sounds like something you do
2010/1/24 Tom Lane :
> Euler Taveira de Oliveira 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_use
Euler Taveira de Oliveira 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
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}?
Another thing that is not a problem of your
Magnus Hagander writes:
> Here goes.
Looks much saner. One minor stylistic gripe:
+Datum
+pg_stat_reset_single_table(PG_FUNCTION_ARGS)
+{
+ pgstat_reset_single_counter(PG_GETARG_OID(0), RESET_TABLE);
+
+ PG_RETURN_VOID();
+}
I don't like sticking PG_GETARG calls inline in the body
2010/1/24 Magnus Hagander :
> 2010/1/24 Tom Lane :
>> Magnus Hagander writes:
>>> In the spirit of finishing off small patches, attached is the one that
>>> implements pg_stat_reset_single(), to be able to reset stats for a
>>> single table or function. I kind of thought it would be included in
>>
On Sun, 2010-01-24 at 18:25 +0100, Magnus Hagander wrote:
> 2010/1/24 Tom Lane :
> > Magnus Hagander writes:
> >> In the spirit of finishing off small patches, attached is the one that
> >> implements pg_stat_reset_single(), to be able to reset stats for a
> >> single table or function. I kind of
2010/1/24 Tom Lane :
> Magnus Hagander writes:
>> In the spirit of finishing off small patches, attached is the one that
>> implements pg_stat_reset_single(), to be able to reset stats for a
>> single table or function. I kind of thought it would be included in
>> the patch from Greg Smith for sha
Magnus Hagander writes:
> In the spirit of finishing off small patches, attached is the one that
> implements pg_stat_reset_single(), to be able to reset stats for a
> single table or function. I kind of thought it would be included in
> the patch from Greg Smith for shared counters so I put it as
In the spirit of finishing off small patches, attached is the one that
implements pg_stat_reset_single(), to be able to reset stats for a
single table or function. I kind of thought it would be included in
the patch from Greg Smith for shared counters so I put it aside, but I
guess I misunderstood
13 matches
Mail list logo