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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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