Re: [HACKERS] Location for pgstat.stat

[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 all.

That's not actualliy not affected, but it does seem like it wouldn't be

a very big issue. If one table was just about to be vacuumed or
analyzed, this would just push it up to twice the threshold, right?

Except you could lather, rinse, repeat indefinitely.

The stats system started out with the idea that the stats were
disposable, but I don't really think that's an acceptable behavior
today.  We don't even have stats_reset_on_server_start anymore.


stats file --- it'd just take another parameter to the read and write

and a shutdown write ...

It doesn't seem to me that it'd be hard to support two locations for the routines. pgstat.c already knows the difference between a normal write

--
Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828

Leaving the realm of "an easy change", what about periodically (once a minute?) writing stats to a real table? That means we should never have to suffer corrupted or lost stats on a crash. Along the same lines, perhaps we can just keep updates in shared memory instead of in a file, since that's proven to cause issues for some people.

smime.p7s
Description: S/MIME cryptographic signature