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 5308.1478790672@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  (otar shavadze <oshavadze@gmail.com>)
Responses Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists
List pgsql-general
otar shavadze <oshavadze@gmail.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


pgsql-general by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Row level security performance joining large tables
Next
From: Kim Rose Carlsen
Date:
Subject: Re: How to hint 2 coulms IS NOT DISTINCT FROM each other