Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Attached is a patch that implements this. I went with the option of just
>> storing it in a temporary directory that can be symlinked, and not
>> bothering with a GUC for it. Comments? (documentation updates are also
>> needed, but I'
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Attached is a patch that implements this. I went with the option of just
> storing it in a temporary directory that can be symlinked, and not
> bothering with a GUC for it. Comments? (documentation updates are also
> needed, but I'll wait with those unt
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> It doesn't seem to me that it'd be hard to support two locations for the
>>> stats file --- it'd just take another parameter to the read and write
>>> routines. pgstat.c already knows the difference between a norm
Decibel! <[EMAIL PROTECTED]> writes:
> Leaving the realm of "an easy change", what about periodically (once
> a minute?) writing stats to a real table?
The ensuing vacuum overhead seems a sufficient reason why not.
regards, tom lane
--
Sent via pgsql-hackers mailing li
On Jul 1, 2008, at 3:02 PM, Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Alvaro Herrera wrote:
Well, it doesn't :-) No database or table will be processed
until stat
entries are created, and then I think it will first wait until
enough
activity gathers to take any actions at
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It doesn't seem to me that it'd be hard to support two locations for the
>> stats file --- it'd just take another parameter to the read and write
>> routines. pgstat.c already knows the difference between a normal write
>> and a shut
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Alvaro Herrera wrote:
>>> Well, it doesn't :-) No database or table will be processed until stat
>>> entries are created, and then I think it will first wait until enough
>>> activity gathers to take any actions at all.
>
>> That's
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Well, it doesn't :-) No database or table will be processed until stat
>> entries are created, and then I think it will first wait until enough
>> activity gathers to take any actions at all.
> That's not actualliy not affecte
On Tue, 1 Jul 2008, Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Hmm ... that would almost certainly result in the stats being lost over
a system shutdown. How much do we care?
Only for those who put it on a ramdrive. The default, unless you
move/sync it off,
Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
>> Not sure. I guess my own personal concern would be how badly is
>> autovacuum affected by having to start off a blank set of stats? Any
>> other uses I have I think are capable of dealing with reset-to-zero states.
>
> Well, it doesn't :-) No d
Magnus Hagander wrote:
> Not sure. I guess my own personal concern would be how badly is
> autovacuum affected by having to start off a blank set of stats? Any
> other uses I have I think are capable of dealing with reset-to-zero states.
Well, it doesn't :-) No database or table will be processe
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Hmm ... that would almost certainly result in the stats being lost over
>>> a system shutdown. How much do we care?
>
>> Only for those who put it on a ramdrive. The default, unless you
>> move/sync it off, would
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm ... that would almost certainly result in the stats being lost over
>> a system shutdown. How much do we care?
> Only for those who put it on a ramdrive. The default, unless you
> move/sync it off, would still be the same as it
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> But pending that we have that, how about we just move it into it's own
>> subdirectory?
>> This would make it possible to symlink or mount that directory off to a
>> ramdrive (for example).
>
> Hmm ... that would almost certainly res
Magnus Hagander <[EMAIL PROTECTED]> writes:
> But pending that we have that, how about we just move it into it's own
> subdirectory?
> This would make it possible to symlink or mount that directory off to a
> ramdrive (for example).
Hmm ... that would almost certainly result in the stats being los
Per this thread:
http://archives.postgresql.org/pgsql-general/2007-12/msg00255.php
it was pretty much (again, IIRC) concluded that we want "some better
way" to transfer the stats data.
But pending that we have that, how about we just move it into it's own
subdirectory? AFAICS that would be a simp
16 matches
Mail list logo
