Re: temporary statistics option at initdb time

On Aug 13, 2008, at 4:12 AM, Magnus Hagander wrote:
> Tom Lane wrote:
>> Decibel! <decibel@decibel.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@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828