Re: feature: dynamic DB cache resizing

From: "Ed L(dot)" <pgsql-general(at)bluepolka(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: feature: dynamic DB cache resizing
Date: 2005-12-05 22:30:19
Message-ID: 200512051530.19369.pgsql-general@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Monday December 5 2005 3:17 pm, Tom Lane wrote:
> There isn't any particularly good reason to be resizing
> shared_buffers on the fly anyway; much easier to let the
> kernel adapt the size of its disk cache instead.  Best
> practice for shared_buffers is to set it somewhere in the
> range of 10K to 50K and forget it.

Oh, how I wish it were so on these boxes. However, HP gurus tell
me that OS dynamic buffer caches larger than ~800MB +/- slop
have diminishing returns due to contention between vhand and
others. Therefore, to most effectively take advantage of a big
multi-cluster box with gobs of RAM for DB caching, it seems to
me I need to specifically allocate the available RAM among the
DB clusters. [This is a pain and I'd much rather the OS did it
for me.] Of course, we don't know how many clusters we'll have
and of what size when we start. Thus, the need for resizing the
DB caches as new clusters come online. Does that make sense?

Ed

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephan Vollmer 2005-12-05 22:37:44 Re: ILIKE '%term%' and Performance
Previous Message Tom Lane 2005-12-05 22:19:58 Re: EXPLAIN SELECT .. does not return