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

@Jeff

> most_common_elems. Is it empty, or is it not empty? If not empty, does
> it contain the specific values you used in your queries?

No, most_common_elems is not empty. it contain the specific values I used
in queries.

@Tom

>
> Hmmm ... actually, I wonder if maybe '@>' here is the contrib/intarray
> operator not the core operator? The intarray operator didn't get plugged
> into any real estimation logic until 9.6.

So, you mean that better would be go to version 9.6 ?

On Wed, Nov 9, 2016 at 8:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I wrote:
> > 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.
>
> Hmmm ... actually, I wonder if maybe '@>' here is the contrib/intarray
> operator not the core operator? The intarray operator didn't get plugged
> into any real estimation logic until 9.6.
>
> regards, tom lane
>