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: 1212424157.4120.371.camel@ebony.site (view raw or flat)
Thread:
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)

Agreed.

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
backend:
	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           www.2ndQuadrant.com
 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-2014 The PostgreSQL Global Development Group