Bruce Momjian [EMAIL PROTECTED] writes:
It all works now and I have just submitted it to -patches as a
new contrib,
but it probably should make its way into the backend one day.
OK, the big question is how do we want to make stats reset visible to
users? The current patch uses a
On Tue, Jul 30, 2002 at 04:21:24PM -0400, Tom Lane wrote:
However, the real question is what is the use-case for this feature
anyway. Why should people want to reset the stats while the system
is running? If we had a clear example then it might be more apparent
what restrictions to place on
Christopher Kings-Lynne wrote:
OK, now I run it and it does absolutely nothing to the pg_stat_all_tables
relation for instance. In fact, it seems to do nothing at all - does the
reset function even work?
OK, I'm an idiot, I was calling the funciton like this: void blah(void)
which
Bruce Momjian [EMAIL PROTECTED] writes:
It all works now and I have just submitted it to -patches as a new contrib,
but it probably should make its way into the backend one day.
OK, the big question is how do we want to make stats reset visible to
users? The current patch uses a function
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
It all works now and I have just submitted it to -patches as a new contrib,
but it probably should make its way into the backend one day.
OK, the big question is how do we want to make stats reset visible to
users? The current
Bruce Momjian [EMAIL PROTECTED] writes:
A function seems like the wrong way to go on this. SET has super-user
protections we could use to control this but I am not sure what SET
syntax to use.
I don't like SET for it --- SET is for setting state that will persist
over some period of time,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
A function seems like the wrong way to go on this. SET has super-user
protections we could use to control this but I am not sure what SET
syntax to use.
I don't like SET for it --- SET is for setting state that will persist
over
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't like SET for it --- SET is for setting state that will persist
over some period of time, not for taking one-shot actions. We could
perhaps use a function that checks that it's been called by the
superuser.
Should we have
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't like SET for it --- SET is for setting state that will persist
over some period of time, not for taking one-shot actions. We could
perhaps use a function that checks that it's been called by the
superuser.
Or you might have made a number of changes to a database which has
been running for a while, and want to see whether the changes have
had the desired effect. (Say, whether some new index has helped
things.)
Well out stats had gotten up in to the millions and hence were useless when
I made
, 29 July 2002 2:19 PM
To: Christopher Kings-Lynne
Cc: Jan Wieck; Hackers
Subject: Re: [HACKERS] [GENERAL] Stats Collector
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is it something to do with the return type being declared wrongly?
Yup. Make it return a useless '1' or 'true
OK, now I run it and it does absolutely nothing to the pg_stat_all_tables
relation for instance. In fact, it seems to do nothing at all - does the
reset function even work?
OK, I'm an idiot, I was calling the funciton like this: void blah(void)
which actually does nothing.
It all works now
Looks to me, someone forgot something. That would be me and now I
remember that I originally wanted to add some utility command for that.
What you need in the meantime is a little C function that calls
void pgstat_reset_counters(void);
I might find the time tomorrow to write one for you
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is it something to do with the return type being declared wrongly?
Yup. Make it return a useless '1' or 'true' or some such.
regards, tom lane
---(end of broadcast)---
14 matches
Mail list logo
