From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Location for pgstat.stat |
Date: | 2008-07-02 23:47:41 |
Message-ID: | 4779C757-2605-4315-B93E-1610CFC5466F@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul 1, 2008, at 3:02 PM, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)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(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2008-07-03 00:00:11 | Re: Limits of backwards compatibility for psql's \d commands |
Previous Message | Decibel! | 2008-07-02 23:39:01 | Re: Limits of backwards compatibility for psql's \d commands |