Re: 2nd Level Buffer Cache - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: 2nd Level Buffer Cache
Date
Msg-id 9B2A55FF-2238-482F-848D-F19131883743@nasby.net
Whole thread Raw
In response to Re: 2nd Level Buffer Cache  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: 2nd Level Buffer Cache
Re: 2nd Level Buffer Cache
List pgsql-hackers
On Mar 18, 2011, at 11:19 AM, Robert Haas wrote:
> On Fri, Mar 18, 2011 at 11:14 AM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
> A related area that could use some looking at is why performance tops
> out at shared_buffers ~8GB and starts to fall thereafter.  InnoDB can
> apparently handle much larger buffer pools without a performance
> drop-off.  There are some advantages to our reliance on the OS buffer
> cache, to be sure, but as RAM continues to grow this might start to
> get annoying.  On a 4GB system you might have shared_buffers set to
> 25% of memory, but on a 64GB system it'll be a smaller percentage, and
> as memory capacities continue to clime it'll be smaller still.
> Unfortunately I don't have the hardware to investigate this, but it's
> worth thinking about, especially if we're thinking of doing things
> that add more caching.

+1

To take the opposite approach... has anyone looked at having the OS just manage all caching for us? Something like
MMAPedshared buffers? Even if we find the issue with large shared buffers, we still can't dedicate serious amounts of
memoryto them because of work_mem issues. Granted, that's something else on the TODO list, but it really seems like
we'rere-inventing the wheels that the OS has already created here... 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




pgsql-hackers by date:

Previous
From: Dan Ports
Date:
Subject: Re: SSI bug?
Next
From: Alvaro Herrera
Date:
Subject: Re: Sync Rep and shutdown Re: Sync Rep v19