From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: contrib/intarray (was Re: Fixing GIN for empty/null/full-scan cases) |
Date: | 2011-01-08 22:04:03 |
Message-ID: | 0B0AD41C-BB93-4B43-9B53-D4063FCA9252@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2011-01-08 22:37:06 | Re: Wildcard search support for pg_trgm |
Previous Message | Tom Lane | 2011-01-08 21:59:11 | contrib/intarray (was Re: Fixing GIN for empty/null/full-scan cases) |