Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: otar shavadze <oshavadze(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists
Date: 2016-11-08 23:05:05
Message-ID: 1458.1478646305@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

otar shavadze <oshavadze(at)gmail(dot)com> writes:
> " -> Bitmap Index Scan on idx (cost=0.00..23.80 rows=533
> width=0) (actual time=35.054..35.054 rows=90052 loops=1)"
> " Index Cond: (my_array @> '{8}'::integer[])"

Seems like your problem here is that the planner has no idea about the
selectivity of this condition --- if it did, I think it would have
made the right choice, because it would have made a much higher estimate
for the cost of the indexscan.

AFAICT, Postgres 9.5 does make a reasonably correct guess when given
up-to-date stats. I speculate that you need to ANALYZE this table.
If there are a lot of distinct possible values in the arrays, increasing
the statistics target for the column might be needed.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2016-11-09 02:02:54 Re: which work memory parameter is used for what?
Previous Message Karl Czajkowski 2016-11-08 22:41:19 Re: resolution order for foreign key actions?