On Fri, Mar 18, 2011 at 11:14 AM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Maybe the thing to focus on first is the oft-discussed "benchmark > farm" (similar to the "build farm"), with a good mix of loads, so > that the impact of changes can be better tracked for multiple > workloads on a variety of platforms and configurations. Without > something like that it is very hard to justify the added complexity > of an idea like this in terms of the performance benefit gained.
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
