Re: Move PinBuffer and UnpinBuffer to atomics - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Move PinBuffer and UnpinBuffer to atomics
Date
Msg-id 20150915145633.GB16920@alap3.anarazel.de
Whole thread Raw
In response to Re: Move PinBuffer and UnpinBuffer to atomics  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Move PinBuffer and UnpinBuffer to atomics  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
On 2015-09-15 08:07:57 -0500, Merlin Moncure wrote:
> Are you confident this is faster across all workloads?

No. This is a proof of concept I just wrote & posted because I didn't
see the patch moving in the right direction. But I do think it can be
made faster in all relevant workloads.

> Pin/Unpin are probably faster but this comes at a cost of extra atomic
> ops during the clock sweep loop.  I wonder if this will degrade
> results under heavy contention.

I think it's actually going to be faster under contention, and the
situation where it's slower is uncontended workloads where you a very
very low cache hit ratio.

> Also, I'm curious about your introduction of __builtin_expect()
> macros.  Did you measure any gain from them?

I introduced them because I was bothered by the generated assembler ;)

But a bit more seriously, I do think there's some benefit in influencing
the code like that. I personally also find they *increase* readability
in cases like this where the likely() branch should be taken just about
all the time.

> I bet there are other places they could be used -- for example the
> mvcc hint bit checks on xmin.

I don't think those are good candidates, there's too many cases where
it's common to have the majority of cases go the other way.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Move PinBuffer and UnpinBuffer to atomics
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.