Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Tom Lane wrote:
> >> Andrew Sullivan <andrew@libertyrms.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.
> >
> > Agreed, we can't resize shared memory, but I don't think most OS's swap
> > out shared memory, and even if they do, they usually have a kernel
>
> We can't resize shared memory because we allocate the whole thing in one
> big hump - which causes the shmmax problem BTW. If we allocate that in
> chunks of multiple blocks, we only have to give it a total maximum size
> to get the hash tables and other stuff right from the beginning. But the
> vast majority of memory, the buffers themself, can be made adjustable at
> runtime.
That is an interesting idea.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
