Re: contrib/intarray (was Re: Fixing GIN for empty/null/full-scan cases)

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