Re: temporary statistics option at initdb time - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: temporary statistics option at initdb time
Date
Msg-id 48A2A58A.50808@hagander.net
Whole thread Raw
In response to Re: temporary statistics option at initdb time  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: temporary statistics option at initdb time  (Magnus Hagander <magnus@hagander.net>)
Re: temporary statistics option at initdb time  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
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.

But I can certainly look at making it a startup GUC. As you say, that'll
solve *most* of the cases.

//Magnus


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Transaction-controlled robustness for replication
Next
From: Magnus Hagander
Date:
Subject: Re: Replay attack of query cancel