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

Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date: 2013-01-08 14:53:29
Message-ID: CAGTBQpZN56Unfs4wGiSkTyae0K9QXfqyjYsjazrX=ZoMp1OpMQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Jan 8, 2013 at 11:39 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> Reference: http://postgresql.1045698.n5.nabble.com/Simple-join-doesn-t-use-index-td5738689.html
>
> This is a pretty common gotcha: user sets shared_buffers but misses
> the esoteric but important effective_cache_size.  ISTM
> effective_cache_size should always be >= shared buffers -- this is a
> soft configuration error that could be reported as a warning and
> perhaps overridden on the fly.

Not true. If there are many concurrent users running concurrent
queries against parallel databases, such as some test systems I have
that contain many databases for many test environments, such a setting
wouldn't make sense. If a DBA sets it to lower than shared_buffers,
that setting has to be honored.

Rather, I'd propose the default setting should be "-1" or something
"default" and "automagic" that works most of the time (but not all).


In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2013-01-08 14:58:51
Subject: Re: json api WIP patch
Previous:From: Claudio FreireDate: 2013-01-08 14:51:06
Subject: Re: Improve compression speeds in pg_lzcompress.c

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