On Mon, Jan 18, 2010 at 11:02, Magnus Hagander wrote:
> On Mon, Jan 18, 2010 at 00:52, Greg Smith wrote:
>> Magnus Hagander wrote:
>>>
>>> Maybe this should be "Unrecognized reset target: %s", target, and also
>>> a errhint() saying which targets are allowed. Thoughts?
>>>
>>
>> That seems reason
On Mon, Jan 18, 2010 at 00:52, Greg Smith wrote:
> Magnus Hagander wrote:
>>
>> Maybe this should be "Unrecognized reset target: %s", target, and also
>> a errhint() saying which targets are allowed. Thoughts?
>>
>
> That seems reasonable. The other thing I realized is that I forgot to add
> the
Magnus Hagander wrote:
Maybe this should be "Unrecognized reset target: %s", target, and also
a errhint() saying which targets are allowed. Thoughts?
That seems reasonable. The other thing I realized is that I forgot to
add the new function to the right place in doc/src/sgml/func.sgml :
2010/1/14 Greg Smith :
> Itagaki Takahiro wrote:
>>
>> To be honest, I have a plan to add performance statistics counters to
>> postgres. It is not bgwriter's counters, but cluster-level. I'd like
>> to use your infrastructure in my work, too :)
>>
>
> Attached patch provides just that. It still wo
On Thu, Jan 14, 2010 at 1:11 PM, Tom Lane wrote:
> Greg Smith writes:
>> Tom Lane wrote:
>>> Actually, that brings up a more general question: what's with the
>>> enthusiasm for clearing statistics *at all*?
>
>> ... Right now, you're still carrying around
>> the history of the bad period forever
Itagaki Takahiro wrote:
To be honest, I have a plan to add performance statistics counters to
postgres. It is not bgwriter's counters, but cluster-level. I'd like
to use your infrastructure in my work, too :)
Attached patch provides just that. It still works basically the same as
my earlier
Greg Smith wrote:
>
>> Before 8.3, we had the stats_reset_on_server_start parameter and
>> the pg_postmaster_start_time() function. This was an easy way of
>> resetting *all* statistics delivered by pg_stat_* and knowing when
>> this was done. We were able to produce stats with information about
>
Tom Lane wrote:
Seems like a more appropriate solution would be to make it easier to do
that subtraction, ie, make it easier to capture the values at a given
time point and then get deltas from there. It's more general (you could
have multiple saved sets of values), and doesn't require superuser
Greg Smith writes:
> Tom Lane wrote:
>> Actually, that brings up a more general question: what's with the
>> enthusiasm for clearing statistics *at all*?
> ... Right now, you're still carrying around
> the history of the bad period forever though, and every check of the
> pg_stat_bgwriter requi
Rafael Martinez wrote:
One thing I miss from the statistics you can get via pg_stat_* is
information about how long we have been collecting stats (or in other
words, when was the last time the stats were reset)
I've considered adding this for the same reasons you're asking about it,
but am
2010/1/14 Tom Lane :
> Rafael Martinez writes:
>> Is there any chance of implementing a way of knowing when was the last
>> time statistics delivered via pg_stat_* were reset?
>
> Actually, that brings up a more general question: what's with the
> enthusiasm for clearing statistics *at all*? ISTM
Euler Taveira de Oliveira wrote:
Greg Smith escreveu:
pg_stat_reset( which text )
which := 'buffers' | 'checkpoints' | 'tables' | 'functions' | ...
What about adding 'all' too? Or the idea is resetting all global counters when
we call pg_stat_reset() (without parameters)?
O
Tom Lane wrote:
Actually, that brings up a more general question: what's with the
enthusiasm for clearing statistics *at all*? ISTM that's something
you should do only in dire emergencies, like the collector went
haywire and has now got a bunch of garbage numbers. The notion of
resetting subset
Rafael Martinez writes:
> Is there any chance of implementing a way of knowing when was the last
> time statistics delivered via pg_stat_* were reset?
Actually, that brings up a more general question: what's with the
enthusiasm for clearing statistics *at all*? ISTM that's something
you should d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg Smith wrote:
> Magnus Hagander wrote:
>> I have on my TODO to implement the ability to do stats reset on a
>> single object (say, one table only). Please take this into
>> consideration when you design/name this, so theres no unnecessary
>> overla
2010/1/12 Greg Smith :
> Magnus Hagander wrote:
>>
>> I have on my TODO to implement the ability to do stats reset on a
>> single object (say, one table only). Please take this into
>> consideration when you design/name this, so theres no unnecessary
>> overlap :-) Same goes for the stats message i
Greg Smith escreveu:
> pg_stat_reset( which text )
> which := 'buffers' | 'checkpoints' | 'tables' | 'functions' | ...
>
What about adding 'all' too? Or the idea is resetting all global counters when
we call pg_stat_reset() (without parameters)?
--
Euler Taveira de Oliveira
http://ww
Magnus Hagander wrote:
I have on my TODO to implement the ability to do stats reset on a
single object (say, one table only). Please take this into
consideration when you design/name this, so theres no unnecessary
overlap :-) Same goes for the stats message itself.
The idea suggested upthrea
On sön, 2009-12-06 at 19:50 -0500, Greg Smith wrote:
> The fact that you're asking the question this way suggests to me I've
> named this completely wrong. pg_stat_reset_global only resets the
> bits
> global to all databases. It doesn't touch any of the
> database-specific
> things that pg_st
2009/12/7 Greg Smith :
> Itagaki Takahiro wrote:
>
> Greg Smith wrote:
>
>
>
> I'm thinking that I should rename this new function
> to pg_stat_reset_bgwriter so it's obvious how limited its target is.
>
>
> I don't think it is a good name because we might have another cluster-level
> statictics n
Itagaki Takahiro wrote:
Greg Smith wrote:
I'm thinking that I should rename this new function
to pg_stat_reset_bgwriter so it's obvious how limited its target is.
I don't think it is a good name because we might have another cluster-level
statictics not related with bgwriter in the f
Greg Smith wrote:
> I'm thinking that I should rename this new function
> to pg_stat_reset_bgwriter so it's obvious how limited its target is.
I don't think it is a good name because we might have another cluster-level
statictics not related with bgwriter in the future. I hope you will suggest
Itagaki Takahiro wrote:
Greg Smith wrote:
-Not sure if this should be named pg_stat_rest_global (to match the way
these are called "global stats" in the source) or
pg_stat_reset_cluster. Picked the former for V1, not attached to that
decision at all. Might even make sense to use a name
Greg Smith wrote:
> This implements the TODO item "Allow the
> clearing of cluster-level statistics", based on previous discussion
> ending at http://archives.postgresql.org/pgsql-hackers/2009-03/msg00920.php
> -Not sure if this should be named pg_stat_rest_global (to match the way
> these a
Since the pg_stat_bgwriter structure was introduced in 8.3, there's
never been any way to reset its statistics back to 0. A week of
analyzing data from that every day drove me crazy enough to finally fix
this with the attached patch. This implements the TODO item "Allow the
clearing of cluste
25 matches
Mail list logo
