On Mar 25, 2011, at 10:07 AM, Gurjeet Singh wrote: > On Tue, Mar 22, 2011 at 3:53 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Mar 22, 2011 at 11:24 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > > On Fri, Mar 18, 2011 at 9:19 AM, Robert Haas <robertmh...@gmail.com> wrote: > >> 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. > > > > Under what circumstances does this happen? Can a simple pgbench -S > > with a large scaling factor elicit this behavior? > > To be honest, I'm mostly just reporting what I've heard Greg Smith say > on this topic. I don't have any machine with that kind of RAM. > > I can sponsor a few hours (say 10) of one High-memory on-demand Quadruple > Extra Large instance (26 EC2 Compute Units (8 virtual cores with 3.25 EC2 > Compute Units each), 1690 GB of local instance storage, 64-bit platform). > That's the largest memory AWS has.
Related to that... after talking to Greg Smith at PGEast last night, he felt it would be very valuable just to profile how much time is being spent waiting/holding the freelist lock in a real environment. I'm going to see if we can do that on one of our slave databases. -- 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
