Re: temporary statistics option at initdb time

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: temporary statistics option at initdb time
Дата
Msg-id 48A2A58A.50808@hagander.net
обсуждение исходный текст
Ответ на Re: temporary statistics option at initdb time  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: temporary statistics option at initdb time
Re: temporary statistics option at initdb time
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Transaction-controlled robustness for replication
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Replay attack of query cancel