On Mar 18, 2011, at 11:19 AM, Robert Haas wrote: > On Fri, Mar 18, 2011 at 11:14 AM, Kevin Grittner > <kevin.gritt...@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 MMAPed shared buffers? Even if we find the issue with large shared buffers, we still can't dedicate serious amounts of memory to them because of work_mem issues. Granted, that's something else on the TODO list, but it really seems like we're re-inventing the wheels that the OS has already created here... -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
