On Sat, Aug 6, 2011 at 1:43 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > The approach is to move the important things from a LWLock to a > spinlock, and to not do any locking for increments to clock-hand > increment and numBufferAllocs. > That means that some buffers might occasionally get inspected twice > and some might not get inspected at all during any given clock cycle, > but this should not lead to any correctness problems. (Disclosure: > Tom didn't like this approach when it was last discussed.) > > I just offer this for whatever it is worth to you--I'm not proposing > it as an actual patch to be applied.
Interesting approach. > When data fits in RAM but not shared_buffers, maybe the easiest fix is > to increase shared_buffers. Which brings up the other question I had > for you about your work with Nate's celebrated loaner machine. Have > you tried to reproduce the performance problems that have been > reported (but without public disclosure of how to reproduce) with > shared_buffers > 8GB on machines with RAM >>8GB ? No. That's on my list, but thus far has not made it to the top of said list. :-( -- 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
