From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
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 14:56:33 |
Message-ID: | 20150915145633.GB16920@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-09-15 14:58:49 | Re: [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references. |
Previous Message | Andres Freund | 2015-09-15 14:50:44 | Re: Move PinBuffer and UnpinBuffer to atomics |