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

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
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?

			regards, tom lane

In response to


pgsql-performance by date

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

pgsql-hackers by date

Next:From: SHARMILA JOTHIRAJAHDate: 2009-02-12 21:32:48
Subject: Re: Good Delimiter for copy command
Previous:From: Andrew GouldDate: 2009-02-12 21:15:06
Subject: Re: Good Delimiter for copy command

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