From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-sql <pgsql-sql(at)postgresql(dot)org> |
Subject: | Gist indexes on int arrays |
Date: | 2003-03-03 21:29:18 |
Message-ID: | 87wujgi1g1.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
> What do you mean??
> GiST indexing just indexes columns of type *array* for the &&,=,@,~,@@,
> etc.. operators.
Hm, you're right of course. I wonder where I got the idea that it didn't
handle these operators.
This is fascinating and could be useful for something I'm working on.
How do gist indexes interact with more normal data types to index? I have a
situation where I have a table with millions of records, and I'm mostly
operating on a subset of those records, usually 1k-10k of them.
The queries would look like
WHERE foo_id = ?
AND '{1}'::integer[] ~ attr_a
AND '{2}'::integer[] ~ attr_b
Right now I'm using the contrib/array *= operator and I have an index on
foo_id. Having to scan through up to 10,000 records isn't great but isn't too
bad. I wonder whether having a gist index and using the ~ operator would be
worthwhile?
The contrib/array, contrib/intagg, and contrib/intarray directories seem to
all be aimed at handling the same thing and seem to provide mostly
complementary features. Perhaps they should all be merged into one package. I
guess it does show there's lots of demand for this type of datatype.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-03-03 22:09:04 | Re: Forcing query to use an index |
Previous Message | Michael Nachbaur | 2003-03-03 21:05:22 | Forcing query to use an index |