Re: [HACKERS] Location for pgstat.stat

2008-08-05 Thread Magnus Hagander
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

Re: [HACKERS] Location for pgstat.stat

2008-08-04 Thread Magnus Hagander
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

Re: [HACKERS] Location for pgstat.stat

2008-08-04 Thread Tom Lane
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

Re: [HACKERS] Location for pgstat.stat

2008-07-02 Thread Magnus Hagander
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

Re: [HACKERS] Location for pgstat.stat

2008-07-02 Thread Tom Lane
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

Re: [HACKERS] Location for pgstat.stat

2008-07-02 Thread Decibel!
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

Re: [HACKERS] Location for pgstat.stat

2008-07-02 Thread Tom Lane
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

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Tom Lane
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

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Magnus Hagander
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

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Tom Lane
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

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Magnus Hagander
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

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Alvaro Herrera
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

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Magnus Hagander
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

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Greg Smith
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,

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Tom Lane
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