Skip site navigation (1) Skip section navigation (2)

Re: Overhauling GUCS

From: "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Overhauling GUCS
Date: 2008-06-02 15:59:21
Message-ID: 484418D9.5040608@sun.com (view raw or flat)
Thread:
Lists: pgsql-hackers

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)



-Jignesh

> * It's always unclear which GUCs can be changed, and when. That is much
> more infrequently understood than the meaning of them.
>
> * We should rename effective_cache_size to something that doesn't sound
> like it does what shared_buffers does
>
> * There is no config verification utility, so if you make a change and
> then try to restart and it won't, you are in trouble.
>
>   

In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2008-06-02 16:03:06
Subject: Proposal: new function array_init
Previous:From: Chris BrowneDate: 2008-06-02 15:52:05
Subject: Re: Core team statement on replication in PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group