Re: [PERFORM] GIST versus GIN indexes for intarrays

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rusty Conover <rconover(at)infogears(dot)com>
Cc: psql performance <pgsql-performance(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: [PERFORM] GIST versus GIN indexes for intarrays
Date: 2009-02-12 21:29:38
Message-ID: 17021.1234474178@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message SHARMILA JOTHIRAJAH 2009-02-12 21:32:48 Re: Good Delimiter for copy command
Previous Message Andrew Gould 2009-02-12 21:15:06 Re: Good Delimiter for copy command

Browse pgsql-performance by date

  From Date Subject
Next Message milos d 2009-02-12 23:49:46 Re: col1 ILIKE 'foo%' not behaving the same as lower(col1) LIKE 'foo%'
Previous Message Rusty Conover 2009-02-12 21:05:02 Re: GIST versus GIN indexes for intarrays