| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | John Major <major(at)cbio(dot)mskcc(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Help w/speeding up range queries? |
| Date: | 2006-11-07 01:37:13 |
| Message-ID: | 1B6C24F3-1929-40B0-994D-79A61B6EAA99@nasby.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Oct 31, 2006, at 8:29 PM, Tom Lane wrote:
> John Major <major(at)cbio(dot)mskcc(dot)org> writes:
>> My problem is, I often need to execute searches of tables like these
>> which find "All features within a range".
>> Ie: select FeatureID from SIMPLE_TABLE where
>> FeatureChromosomeName like
>> 'chrX' and StartPosition > 1000500 and EndPosition < 2000000;
>
> A standard btree index is just going to suck for these types of
> queries;
> you need something that's actually designed for spatial range queries.
> You might look at the contrib/seg module --- if you can store your
> ranges as "seg" datatype then the seg overlap operator expresses what
> you need to do, and searches on an overlap operator can be handled
> well
> by a GIST index.
>
> Also, there's the PostGIS stuff, though it might be overkill for what
> you want.
Another possibility (think Tom has suggested in the past) is to
define Start and End as a box, and then use the geometric functions
built into plain PostgreSQL (though perhaps that's what he meant by
"PostGIS stuff").
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2006-11-07 01:52:09 | Re: Easy read-heavy benchmark kicking around? |
| Previous Message | Cosimo Streppone | 2006-11-06 21:33:16 | Re: Context switch storm |