On Mon, Jan 18, 2010 at 11:02, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 18, 2010 at 00:52, Greg Smith g...@2ndquadrant.com wrote:
Magnus Hagander wrote:
Maybe this should be Unrecognized reset target: %s, target, and also
a errhint() saying which targets are allowed. Thoughts?
On Mon, Jan 18, 2010 at 00:52, Greg Smith g...@2ndquadrant.com 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
2010/1/14 Greg Smith g...@2ndquadrant.com:
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
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 :
On Thu, Jan 14, 2010 at 1:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com 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
2010/1/12 Greg Smith g...@2ndquadrant.com:
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
-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
overlap :-)
Rafael Martinez r.m.guerr...@usit.uio.no 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
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
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)?
2010/1/14 Tom Lane t...@sss.pgh.pa.us:
Rafael Martinez r.m.guerr...@usit.uio.no 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
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
Greg Smith g...@2ndquadrant.com 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
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
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
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
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
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
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
2009/12/7 Greg Smith g...@2ndquadrant.com:
Itagaki Takahiro wrote:
Greg Smith g...@2ndquadrant.com 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
Greg Smith g...@2ndquadrant.com 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
Itagaki Takahiro wrote:
Greg Smith g...@2ndquadrant.com 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
Greg Smith g...@2ndquadrant.com 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
Itagaki Takahiro wrote:
Greg Smith g...@2ndquadrant.com 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
24 matches
Mail list logo
