On Sat, Aug 6, 2011 at 1:43 PM, Jeff Janes <jeff.janes@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
