Re: temporary statistics option at initdb time

Decibel! wrote:
> 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.

Well, it's doable, but fairly hard.

But you can do it the symlink way without shutting it down, I think. :-)

//Magnus