Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date
Msg-id 20140515120604.GA28532@momjian.us
Whole thread Raw
In response to Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Amit Langote <amitlangote09@gmail.com>)
Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, May  6, 2014 at 11:15:17PM +0100, Simon Riggs wrote:
> > Well, for what it's worth, I've encountered systems where setting
> > effective_cache_size too low resulted in bad query plans, but I've
> > never encountered the reverse situation.
> 
> I agree with that.
> 
> Though that misses my point, which is that you can't know that all of
> that memory is truly available on a server with many concurrent users.
> Choosing settings that undercost memory intensive plans are not the
> best choice for a default strategy in a mixed workload when cache may
> be better used elsewhere, even if such settings make sense for some
> individual users.

This is the same problem we had with auto-tuning work_mem, in that we
didn't know what other concurrent activity was happening.  Seems we need
concurrent activity detection before auto-tuning work_mem and
effective_cache_size.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Various cosmetic fixes
Next
From: Sergey Muraviov
Date:
Subject: Re: wrapping in extended mode doesn't work well with default pager