Re: Location for pgstat.stat

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

In response to

Responses

Browse pgsql-hackers by date

  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