On Jul 1, 2008, at 3:02 PM, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> 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.
>
> 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 ...
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.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
