Re: Location for pgstat.stat - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Location for pgstat.stat
Date
Msg-id 486B8C42.7090009@hagander.net
Whole thread Raw
In response to Re: Location for pgstat.stat  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Location for pgstat.stat  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

Yeha, but if you do that, you certainly have other problems as well....


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

Good point.


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

Right. Should it be removed from the permanent location when the server
starts? Otherwise, if it crashes, we'll pick up the old, stale, version
of the file since it didn't have a chance to get saved away. Better to
start from an empty file, or to start from one that has old data in it?

//Magnus


pgsql-hackers by date:

Previous
From: Bernd Helmle
Date:
Subject: Re: A Windows x64 port of MySQL
Next
From: "David E. Wheeler"
Date:
Subject: Re: PATCH: CITEXT 2.0