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

From Arnaud L.
Subject Re: Slow statement using parallelism after 9.6>11 upgrade
Date
Msg-id 76820bc0-b570-3f00-1335-51d85f5012e5@codata.eu
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
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



pgsql-general by date:

Previous
From: "Arnaud L."
Date:
Subject: Re: Slow statement using parallelism after 9.6>11 upgrade
Next
From: "Arnaud L."
Date:
Subject: Re: Slow statement using parallelism after 9.6>11 upgrade