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]

 



Le 04/09/2019 à 09:04, Arnaud L. a écrit :
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.

Sorry, I meant 1M+ range.

EXPLAIN ANALYZE select id from planet_osm_ways WHERE nodes && ARRAY[123456789::bigint];

(parallel_workers = 0 on the table as per Paul's recommandation) :

Bitmap Heap Scan on planet_osm_ways (cost=11582.45..3535447.30 rows=1419000 width=8) (actual time=0.198..0.199 rows=1 loops=1)
  Recheck Cond: (nodes && '{123456789}'::bigint[])
  Heap Blocks: exact=1
-> Bitmap Index Scan on planet_osm_ways_nodes_idx (cost=0.00..11227.70 rows=1419000 width=0) (actual time=0.151..0.151 rows=1 loops=1)
        Index Cond: (nodes && '{123456789}'::bigint[])
Planning Time: 0.260 ms
Execution Time: 0.249 ms


Regards
--
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