From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Decibel!" <decibel(at)decibel(dot)org>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
Subject: | Re: temporary statistics option at initdb time |
Date: | 2008-08-13 09:12:42 |
Message-ID: | 48A2A58A.50808@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
But I can certainly look at making it a startup GUC. As you say, that'll
solve *most* of the cases.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-08-13 09:14:05 | Re: Transaction-controlled robustness for replication |
Previous Message | Markus Wanner | 2008-08-13 09:06:17 | Re: Transaction-controlled robustness for replication |