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-09 04:35:48
Message-ID: 14046.1478666148@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Paquier 2016-11-09 06:10:39 Re: ENABLE ROW LEVEL SECURITY cause huge produce of checkpoints
Previous Message Jeff Janes 2016-11-09 04:19:12 Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists