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

Re: Overhauling GUCS

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Overhauling GUCS
Date: 2008-06-02 16:29:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
	if (smart_memory_config)
		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 
 PostgreSQL Training, Services and Support

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-06-02 16:33:30
Subject: Re: Case-Insensitve Text Comparison
Previous:From: Greg SmithDate: 2008-06-02 16:22:21
Subject: Re: Overhauling GUCS

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