Re: temporary statistics option at initdb time

On Aug 13, 2008, at 4:12 AM, Magnus Hagander wrote:
> Tom Lane wrote:
>> Decibel! <decibel(at)decibel(dot)org> writes:
>>> I disagree. While we don't guarantee stats are absolutely up-to-
>>> date,
>>> or atomic I don't think that gives license for them to just
>>> magically
>>> not exist sometimes.
>>
>>> Would it really be that hard to have the system copy the file out
>>> before telling all the other backends of the change?
>>
>> Well, there is no (zero, zilch, nada) use-case for changing this
>> setting
>> on the fly. Why not make it a "frozen at postmaster start" GUC?
>> Seems
>> like that gets all the functionality needed and most of the ease
>> of use.
>
> Oh, there is a use-case. If you run your system and then only
> afterwards
> realize the I/O from the stats file is high enough to be an issue, and
> want to change it.
>
> That said, I'm not sure the use-case is anywhere near common enough to
> put a lot of code into it.

Something to keep in mind as PG is used to build larger systems
'further up the enterprise'... for us to bounce a database at work
costs us a LOT in lost revenue. I don't want to go into specifics,
but it's more than enough to buy a very nice car. :) That's why I
asked how hard it'd be to do this on the fly.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828