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, jeff(dot)janes(at)gmail(dot)com
Subject: Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists
Date: 2016-11-10 15:11:12
Message-ID: 5308.1478790672@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:
>> 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 ?

If you are using that contrib module, and it's capturing this operator
reference, that would probably explain the bad estimate. You could
drop the extension if you're not depending on its other features, or you
could explicitly qualify the operator name ("operator(pg_catalog.@>)"),
or you could upgrade to 9.6 (don't forget to do ALTER EXTENSION ... UPDATE
afterwards).

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Kim Rose Carlsen 2016-11-10 18:40:30 Re: How to hint 2 coulms IS NOT DISTINCT FROM each other
Previous Message Stephen Frost 2016-11-10 14:50:31 Re: Row level security performance joining large tables