Bad estimates on GIN bigint[] index

From: "Arnaud L(dot)" <arnaud(dot)listes(at)codata(dot)eu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Bad estimates on GIN bigint[] index
Date: 2019-09-06 10:26:03
Message-ID: f1461562-d347-0168-6ec9-670864b6eb1a@codata.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Le 03/09/2019 à 15:43, Tom Lane a écrit :
> "Arnaud L." <arnaud(dot)listes(at)codata(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kevin Brannen 2019-09-06 15:05:33 RE: SQL equivalint of #incude directive ?
Previous Message Andreas Joseph Krogh 2019-09-06 09:34:08 RE: Primary Key Update issue ?