Skip site navigation (1) Skip section navigation (2)

Re: GIST versus GIN indexes for intarrays

From: Rusty Conover <rconover(at)infogears(dot)com>
To: psql performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: GIST versus GIN indexes for intarrays
Date: 2009-02-13 01:32:43
Message-ID: 4EB92524-5225-44EC-8ABB-CD8CF162708A@infogears.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
On Feb 12, 2009, at 2:29 PM, Tom Lane wrote:

> Rusty Conover <rconover(at)infogears(dot)com> writes:
>> The gist__int_ops is the default operator class for integer[] arrays,
>> as shown at:
>> http://www.postgresql.org/docs/current/static/intarray.html
>
> Ah, so you have contrib/intarray installed.
>
> [ pokes at it... ]  Seems like what we have here is another iteration
> of this ancient bug:
> http://archives.postgresql.org/pgsql-committers/2004-01/msg00073.php
> to wit, contrib/intarray is defining its own @> and <@ operators that
> conflict with those since added to the core.  In the case Rusty is
> showing, the @> gets resolved as intarray's @> (because that's an
> exact match, where the core provides anyarray @> anyarray) and then
> this operator is NOT a member of the core-provided GIN opclass for
> integer arrays.
>
> The short-term workaround for Rusty is probably to create his GIN
> index using the intarray-provided gin__int_ops opclass.  But it
> seems to me that we ought to get rid of intarray's @> and <@ operators
> and have the module depend on the core anyarray operators, just as we
> have already done for = and <>.  Comments?

Hi Tom,

For the record using the GIN opclass does resolve the problem for me.   
The indexes are now seeing usage.

Thanks for the help,

Rusty
--
Rusty Conover
rconover(at)infogears(dot)com
InfoGears Inc / GearBuyer.com / FootwearBuyer.com
http://www.infogears.com
http://www.gearbuyer.com
http://www.footwearbuyer.com

In response to

pgsql-performance by date

Next:From: Alexander StauboDate: 2009-02-13 11:53:12
Subject: I/O increase after upgrading to 8.3.5
Previous:From: milos dDate: 2009-02-12 23:49:46
Subject: Re: col1 ILIKE 'foo%' not behaving the same as lower(col1) LIKE 'foo%'

pgsql-hackers by date

Next:From: ITAGAKI TakahiroDate: 2009-02-13 01:57:25
Subject: Re: fillfactor for toast tables is useless?
Previous:From: Andrew DunstanDate: 2009-02-13 01:26:35
Subject: Re: Missing files after make install ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group