Horton

Re: Fix performance of generic atomics

Jesper Pedersen <jesper.pedersen@redhat.com>

View thread View on postgr.es
From: Jesper Pedersen <jesper.pedersen@redhat.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Sokolov Yura <funny.falcon@postgrespro.ru>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-09-06T17:41:27Z
Lists: pgsql-hackers 
Hi Jeff,

On 09/05/2017 03:47 PM, Jeff Janes wrote:
>> 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.
>>
> 
> What scale factor and client count? How many cores per socket?  It looks
> like Sokolov was just starting to see gains at 200 clients on 72 cores,
> using -N transaction.

I have done a run with scale factor 300, and another with 3000 on a 
2S/28C/56T/256Gb w/ 2 x RAID10 SSD machine; up to 200 clients.

I would consider the runs as "noise" as I'm seeing +-1% for all client 
counts, so nothing like Yura is seeing in [1] for the higher client counts.

I did a run with -N too using scale factor 300, using the settings in 
[1], but with same result (+-1%).

[1] 
https://www.postgresql.org/message-id/d62d7d9d473d07e172d799d5a57e70be@postgrespro.ru

Best regards,
  Jesper

Commits

  1. Further marginal hacking on generic atomic ops.

  2. Use more of gcc's __sync_fetch_and_xxx builtin functions for atomic ops.

  3. Remove duplicate reads from the inner loops in generic atomic ops.