Re: performance degredation after upgrade from 9.6 to 12 - Mailing list pgsql-performance

From Jeff Janes
Subject Re: performance degredation after upgrade from 9.6 to 12
Date
Msg-id CAMkU=1xfnGWux2Vx4Nypoz764YC8OxctQtYDXvykiGeMVoZKrg@mail.gmail.com
Whole thread Raw
In response to Re: performance degredation after upgrade from 9.6 to 12  (Mariel Cherkassky <mariel.cherkassky@gmail.com>)
Responses 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>)
List 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 by date:

Previous
From: Mariel Cherkassky
Date:
Subject: Re: performance degredation after upgrade from 9.6 to 12
Next
From: Mariel Cherkassky
Date:
Subject: Re: performance degredation after upgrade from 9.6 to 12