Re: StrategyGetBuffer optimization, take 2 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: StrategyGetBuffer optimization, take 2
Date
Msg-id 20130820065746.GC8558@alap2.anarazel.de
Whole thread Raw
In response to Re: StrategyGetBuffer optimization, take 2  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: StrategyGetBuffer optimization, take 2  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
On 2013-08-19 15:17:44 -0700, Jeff Janes wrote:
> On Wed, Aug 7, 2013 at 7:40 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> 
> > I agree; at least then it's not unambiguously better. if you (in
> > effect) swap all contention on allocation from a lwlock to a spinlock
> > it's not clear if you're improving things; it would have to be proven
> > and I'm trying to keep things simple.
> >
> > Attached is a scaled down version of the patch that keeps the freelist
> > lock but still removes the spinlock during the clock sweep.  This
> > still hits the major objectives of reducing the chance of scheduling
> > out while holding the BufFreelistLock and mitigating the worst case
> > impact of doing so if it does happen.  An even more scaled down
> > version would keep the current logic exactly as is except for
> > replacing buffer lock in the clock sweep with a trylock (which is
> > IMNSHO a no-brainer).
> 
> Since usage_count is unsigned, are you sure that changing the tests
> from "buf->usage_count == 0" to "buf->usage_count <= 0" accomplishes
> what you need it to?  If usage_count gets decremented when it already
> zero, it will wrap around to 65,535, at least on some compilers some
> of the time, won't it?

Overflow of *unsigned* variables is actually defined and will always
wrap around. It's signed variables which don't have such a clear
behaviour.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Gavin Flower
Date:
Subject: Re: Personal note: taking some vacation time in Sep/Oct
Next
From: Pavel Stehule
Date:
Subject: possible enhancing of UPDATE syntax?