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:
> Ah, so you have contrib/intarray installed.
> [ pokes at it... ] Seems like what we have here is another iteration
> of this ancient bug:
> 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?
For the record using the GIN opclass does resolve the problem for me.
The indexes are now seeing usage.
Thanks for the help,
InfoGears Inc / GearBuyer.com / FootwearBuyer.com
In response to
pgsql-performance by date
|Next:||From: Alexander Staubo||Date: 2009-02-13 11:53:12|
|Subject: I/O increase after upgrading to 8.3.5|
|Previous:||From: milos d||Date: 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 Takahiro||Date: 2009-02-13 01:57:25|
|Subject: Re: fillfactor for toast tables is useless?|
|Previous:||From: Andrew Dunstan||Date: 2009-02-13 01:26:35|
|Subject: Re: Missing files after make install ?|