Re: Fix performance of generic atomics
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jesper.pedersen@redhat.com
Cc: Sokolov Yura <funny.falcon@postgrespro.ru>, pgsql-hackers@postgresql.org
Date: 2017-09-05T18:51:51Z
Lists: pgsql-hackers
Jesper Pedersen <jesper.pedersen@redhat.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
Commits
-
Further marginal hacking on generic atomic ops.
- bfea92563c51 11.0 landed
-
Use more of gcc's __sync_fetch_and_xxx builtin functions for atomic ops.
- e09db94c0a5f 11.0 landed
-
Remove duplicate reads from the inner loops in generic atomic ops.
- e530be96859e 11.0 landed