Re: Move PinBuffer and UnpinBuffer to atomics

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: YUriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Move PinBuffer and UnpinBuffer to atomics
Date: 2015-09-15 15:47:03
Message-ID: CAHyXU0xQNEgmi=73kbNx-LpYqf0Ljt6YU2ZEzjcz58==FMBQYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 15, 2015 at 9:56 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2015-09-15 08:07:57 -0500, Merlin Moncure wrote:
>> 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.

right. For posterity, I agree with this.

>> 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.

Maybe, but, consider that penalty vs win is asymmetric. If the hint
bit isn't set, you're doing a lot of other work anyways such that the
branch penalty falls away to noise while if you win the benefits are
significant against the tight tuple scan loop.

Anyways, as it pertains to *this* patch, +1 for adding that feature.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-09-15 15:54:34 Re: [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.
Previous Message Charles Clavadetscher 2015-09-15 15:46:50 Re: [DOCS] Missing COMMENT ON POLICY