Andrew Sullivan <andrew(at)libertyrms(dot)info> writes:
> On Sun, Nov 02, 2003 at 01:00:35PM -0500, Tom Lane wrote:
>> real traction we'd have to go back to the "take over most of RAM for
>> shared buffers" approach, which we already know to have a bunch of
>> severe disadvantages.
> I know there are severe disadvantages in the current implementation,
> but are there in-principle severe disadvantages?
Yes. For one, since we cannot change the size of shared memory
on-the-fly (at least not portably), there is no opportunity to trade off
memory usage dynamically between processes and disk buffers. For
another, on many systems shared memory is subject to being swapped out.
Swapping out dirty buffers is a performance killer, because they must be
swapped back in again before they can be written to where they should
have gone. The only way to avoid this is to keep the number of shared
buffers small enough that they all remain fairly "hot" (recently used)
and so the kernel won't be tempted to swap out any part of the region.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2003-11-03 16:11:36|
|Subject: Re: adding support for posix_fadvise() |
|Previous:||From: Neil Conway||Date: 2003-11-03 15:44:43|
|Subject: Re: adding support for posix_fadvise()|