Postgres Pro
Downloads
Home   >   mailing lists

Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists - Mailing list pgsql-general

From Tom Lane
Subject Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists
Date
Msg-id 14046.1478666148@sss.pgh.pa.us
Whole thread Raw
In response to Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists  (otar shavadze <oshavadze@gmail.com>)
List pgsql-general
Tree view 
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

pgsql-general by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists
Next
From: Michael Paquier
Date:
Subject: Re: ENABLE ROW LEVEL SECURITY cause huge produce of checkpoints