From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: feature: dynamic DB cache resizing |
Date: | 2005-12-05 22:17:53 |
Message-ID: | 3099.1133821073@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Ed L. wrote:
>> We have ~75 pgsql clusters running in environments where downtime
>> comes at a premium cost. We often run multiple clusters on a
>> single box, and find it necessary to adjust the size of the
>> static DB cache as we add or move clusters. Unfortunately, that
>> means some downtime. It would be extremely useful in minimizing
>> downtime to be able to dynamically resize the DB cache without
>> having to restart the cluster. How hard would that be?
> We can't think of how to do because it is all shared memory shared by
> ever forked process --- does that help explain its complexity?
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.
If Ed was thinking of something other than shared_buffers, he should
explain what.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-05 22:19:58 | Re: EXPLAIN SELECT .. does not return |
Previous Message | Joshua D. Drake | 2005-12-05 22:17:17 | Re: EXPLAIN SELECT .. does not return |