Re: [PERFORM] GIST versus GIN indexes for intarrays - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PERFORM] GIST versus GIN indexes for intarrays
Date
Msg-id 17021.1234474178@sss.pgh.pa.us
Whole thread Raw
Responses Re: [PERFORM] GIST versus GIN indexes for intarrays  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
Rusty Conover <rconover@infogears.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?

            regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: DISCARD ALL failing to acquire locks on pg_listen
Next
From: Alvaro Herrera
Date:
Subject: Re: fillfactor for toast tables is useless?