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'll wait
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 normal write
and
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 until I
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 not actualliy
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 shutdown write
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
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 list
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
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 lost
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 result in the
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 is
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 still be the
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 processed
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 database
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,
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 affected, but it
16 matches
Mail list logo
