Re: Experimental patch for inter-page delay in VACUUM - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Experimental patch for inter-page delay in VACUUM
Date
Msg-id 21456.1067874424@sss.pgh.pa.us
Whole thread Raw
In response to Re: Experimental patch for inter-page delay in VACUUM  (Andrew Sullivan <andrew@libertyrms.info>)
Responses Re: Experimental patch for inter-page delay in VACUUM  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: adding support for posix_fadvise()
Next
From: Tom Lane
Date:
Subject: Re: adding support for posix_fadvise()