On Jan 8, 2011, at 1:59 PM, Tom Lane wrote: >> Hrm, the queries I wrote for this sort of thing use intarray: > > I'm going to work on contrib/intarray first (before tsearch etc) > so that you can do whatever testing you want sooner.
No, of course not. > One of the things that first got me annoyed about the whole GIN > situation is that intarray's definitions of the <@ and @> operators were > inconsistent with the core operators of the same names. I believe that > the inconsistency has to go away. Really the only reason that intarray > has its own versions of these operators at all is that it can be faster > than the generic anyarray versions in core. There seem to be three ways > in which intarray is simpler/faster than the generic operators: > > * restricted to integer arrays > * restricted to 1-D arrays > * doesn't allow nulls in the arrays My understanding is that they also perform much better if the values in an integer array are ordered. Does that matter? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
