Search Postgresql Archives

Re: Slow statement using parallelism after 9.6>11 upgrade

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Sep 3, 2019, at 7:06 AM, Arnaud L. <arnaud.listes@xxxxxxxxx> wrote:
> 
> Le 03/09/2019 à 15:43, Tom Lane a écrit :
>> "Arnaud L." <arnaud.listes@xxxxxxxxx> 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
> 
> 







[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux