Re: Slow statement using parallelism after 9.6>11 upgrade
От | Arnaud L. |
---|---|
Тема | Re: Slow statement using parallelism after 9.6>11 upgrade |
Дата | |
Msg-id | 12ad6d06-6897-c3f1-a681-62191fadfa90@codata.eu обсуждение исходный текст |
Ответ на | Re: Slow statement using parallelism after 9.6>11 upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Slow statement using parallelism after 9.6>11 upgrade
Re: Slow statement using parallelism after 9.6>11 upgrade |
Список | pgsql-general |
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: > >> -> Bitmap Index Scan on planet_osm_ways_nodes_idx >> (cost=0.00..11190.36 rows=1420982 width=0) (actual time=0.268..0.268 >> rows=1 loops=1) >> Index Cond: (nodes && '{1}'::bigint[]) > > The planner should be able to do better than that, given up-to-date > statistics on the "nodes" column. Tom, I can confirm that with up to date statistics the planner is still lost. I did a REINDEX to rule out a broken index and the estimate is still in the 100k+ range. Regards -- Arnaud
В списке pgsql-general по дате отправления: