Re: performance degredation after upgrade from 9.6 to 12

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: performance degredation after upgrade from 9.6 to 12
Дата
Msg-id CAMkU=1xfnGWux2Vx4Nypoz764YC8OxctQtYDXvykiGeMVoZKrg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: performance degredation after upgrade from 9.6 to 12  (Mariel Cherkassky <mariel.cherkassky@gmail.com>)
Ответы Re: performance degredation after upgrade from 9.6 to 12  (Mariel Cherkassky <mariel.cherkassky@gmail.com>)
Re: performance degredation after upgrade from 9.6 to 12  (Mariel Cherkassky <mariel.cherkassky@gmail.com>)
Список pgsql-performance
Дерево обсуждения
On Sun, Nov 24, 2019 at 8:52 AM Mariel Cherkassky <mariel.cherkassky@gmail.com> wrote:
Hey Andrew,
It seems that changing this parameter worked for me.
Setting it to zero means that there wont be any parallel workers for one query right ?
Is it something familiar this problem with the gatherers ? 

Your example would not be using parallel workers anyway, regardless of the setting of max_parallel_workers_per_gather, so I don't see how changing this could have worked for you.  Unless you mean it worked in your full test, rather than in your test case. I doubt your test case benchmarking was very reliable to start with, you only show a single execution and didn't indicate you had more unshown ones.

If I do more credible benchmarking, I do get a performance regression but it closer is to 16% than to 3 fold.  And it doesn't depend on the setting of max_parallel_workers_per_gather.  I doubt a regression of this size is even worth investigating.

pgbench -T300 -P5 -f <(echo "select count(*) from test1") -p 9912 -n -M prepared

Cheers,

Jeff

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

Предыдущее
От: Mariel Cherkassky
Дата:
Сообщение: Re: performance degredation after upgrade from 9.6 to 12
Следующее
От: Mariel Cherkassky
Дата:
Сообщение: Re: performance degredation after upgrade from 9.6 to 12