Re: [HACKERS] Fix performance of generic atomics

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [HACKERS] Fix performance of generic atomics
Дата
Msg-id CAMkU=1yN7ZzuRq7WBX916o5CCzaSosozv64qp+e6fd+z+XW5Ag@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Fix performance of generic atomics  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Ответы Re: [HACKERS] Fix performance of generic atomics  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Fix performance of generic atomics  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Список pgsql-hackers
On Tue, Sep 5, 2017 at 11:39 AM, Jesper Pedersen <jesper.pedersen@redhat.com> wrote:
On 09/05/2017 02:24 PM, Tom Lane wrote:
Jesper Pedersen <jesper.pedersen@redhat.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] assorted code cleanup
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Replacing lfirst() with lfirst_node() appropriately in planner.c