On Sun, Jun 12, 2011 at 2:39 PM, Robert Haas <robertmh...@gmail.com> wrote: ... > > Profiling reveals that the system spends enormous amounts of CPU time > in s_lock. LWLOCK_STATS reveals that the only lwlock with significant > amounts of blocking is the BufFreelistLock;
This is curious. Clearly the entire working set fits in RAM, or you wouldn't be getting number like this. But does the entire working set fit in shared_buffers? If so, you shouldn't see any traffic on BufFreelistLock once all the data is read in. I've only seen contention here when all data fits in OS cache memory but not in shared_buffers. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
