> 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 patc
> 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 mad
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
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 w
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 pers
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
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:
> >> 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? T
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 func
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)
> wh
> 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 no
ne
> Sent: Monday, 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
"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)--
> 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 fo
14 matches
Mail list logo
