Re: Fix performance of generic atomics

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jesper(dot)pedersen(at)redhat(dot)com
Cc: Sokolov Yura <funny(dot)falcon(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fix performance of generic atomics
Date: 2017-09-05 18:51:51
Message-ID: 9816.1504637511@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> writes:
> On 09/05/2017 02:24 PM, Tom Lane wrote:
>> Hm, so if we can't demonstrate a performance win, it's hard to justify
>> risking touching this code. What test case(s) did you use?

> I ran pgbench (-M prepared) with synchronous_commit 'on' and 'off' using
> both logged and unlogged tables. Also ran an internal benchmark which
> didn't show anything either.

That may just mean that pgbench isn't stressing any atomic ops very
hard (at least in the default scenario).

I'm tempted to write a little C function that just hits the relevant
atomic ops in a tight loop, and see how long it takes to do a few
million iterations. That would be erring in the opposite direction,
of overstating the importance of atomic ops to real-world scenarios
--- but if we didn't get any win that way, then it's surely in the noise.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-09-05 18:52:30 Re: JIT compiling expressions/deform + inlining prototype v2.0
Previous Message Greg Stark 2017-09-05 18:43:33 Re: JIT compiling expressions/deform + inlining prototype v2.0