Re: Slow statement using parallelism after 9.6>11 upgrade - Mailing list pgsql-general

From Paul Ramsey
Subject Re: Slow statement using parallelism after 9.6>11 upgrade
Date
Msg-id DEDF678D-3412-4550-9DFB-C1B393FCE54B@cleverelephant.ca
Whole thread Raw
In response to Re: Slow statement using parallelism after 9.6>11 upgrade  ("Arnaud L." <arnaud.listes@codata.eu>)
List pgsql-general

> On Sep 3, 2019, at 7:06 AM, Arnaud L. <arnaud.listes@codata.eu> wrote:
>
> Le 03/09/2019 à 15:43, Tom Lane a écrit :
>> "Arnaud L." <arnaud.listes@codata.eu> writes:
>>> We have upgraded our database from 9.6 to 11 (and updated PostGIS from 2.3 to 2.5 as well).
>>> ...
>> Have you re-ANALYZEd the database?  The problem with this query
>> seems to be the spectacularly awful rowcount estimate here:
>
> You mean after the upgrade process ? Yes I have.
> I've juste re-run "ANALYZE table" to rule this out, estimates are the same.
>
> Maybe some statistic target problem ? Estimated number of rows is 284.196.352
> Also, this is a GIN index on a bigint[] column.
>
> I've setup parallel_tuple_cost to 1.0 parallel_setup_cost to 5000.0 for the time being which solves this specific
problem.These value don't look very sensible though, they are very high compared to the default ones. 

You can also leave that setting unchanged and just change the behaviour on your one table:

ALTER TABLE nodes SET ( parallel_workers = 0);

P.

>
> Cheers
> --
> Arnaud
>
>




pgsql-general by date:

Previous
From: "Arnaud L."
Date:
Subject: Re: Slow statement using parallelism after 9.6>11 upgrade
Next
From: Nagendra Bandi
Date:
Subject: Postgres HA issue - Standby server does not start after Mastercompute host is shut down