On Mon, 2008-06-02 at 11:59 -0400, Jignesh K. Shah wrote:
> Simon Riggs wrote:
> > Some other problems I see with GUCs
> > * It's not possible to set one parameter depending upon the setting of
> > another.
> To me this is more critical.. Most people I have seen will increase one
> or few but not all parameters related to memory which can result in loss
> of performance and productivity in figuring out.
> What happened to AvailRAM setting and base all memory gucs on that.
> Ideally PostgreSQL should only create one big memory pool and allow all
> other variables to change runtime via dba or some tuner process or
> customized application as long as total is less than the allocated
> shared_memory and local_memory settings. (This will also reduce the need
> of restarting Postgres if a value needs to be changed)
Right now, we can't even do that in code, let alone in config file.
If we had a smart_memory_config = on then we'd be able to say in the
other_thing = 0.1 * Nbuffers;
but the GUCs are evaluated in alphabetical order, without any way of
putting dependencies between them. So they are notionally orthogonal.
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2008-06-02 16:33:30|
|Subject: Re: Case-Insensitve Text Comparison |
|Previous:||From: Greg Smith||Date: 2008-06-02 16:22:21|
|Subject: Re: Overhauling GUCS |