Bad estimates on GIN bigint[] index - Mailing list pgsql-general

From Arnaud L.
Subject Bad estimates on GIN bigint[] index
Date
Msg-id f1461562-d347-0168-6ec9-670864b6eb1a@codata.eu
Whole thread Raw
In response to Re: Slow statement using parallelism after 9.6>11 upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Le 03/09/2019 à 15:43, Tom Lane a écrit :
> "Arnaud L." <arnaud.listes@codata.eu> writes:
>>    ->  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.


Sorry to up this thread, but is there anything I can do to help the 
planner in this particular case ?
REINDEXing did not help, nor did ANALYZEing with different STATISTICS 
target for this specific column.


Regards
--
Arnaud



pgsql-general by date:

Previous
From: Andreas Joseph Krogh
Date:
Subject: RE: Primary Key Update issue ?
Next
From: Kevin Brannen
Date:
Subject: RE: SQL equivalint of #incude directive ?