| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sokolov Yura <funny(dot)falcon(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fix performance of generic atomics |
| Date: | 2017-09-05 19:47:41 |
| Message-ID: | CAMkU=1yN7ZzuRq7WBX916o5CCzaSosozv64qp+e6fd+z+XW5Ag@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 5, 2017 at 11:39 AM, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com
> wrote:
> On 09/05/2017 02:24 PM, Tom Lane wrote:
>
>> Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> writes:
>>
>>> I have tested this patch on a 2-socket machine, but don't see any
>>> performance change in the various runs. However, there is no regression
>>> either in all cases.
>>>
>>
>> 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.
>
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.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-09-05 20:02:14 | Re: Replacing lfirst() with lfirst_node() appropriately in planner.c |
| Previous Message | Tom Lane | 2017-09-05 19:32:27 | Re: assorted code cleanup |