Thanks, that was the problem: postgres thought it had to typecast the
column to a box type, which prevented use of the index.
For any PostGIS users reading this: the solution is to express the
other operand using a GeometryFromText(...) construct.
Thanks again,
-Greg
On May 5, 2007, at 7:48 AM, Tom Lane wrote:
=?ISO-8859-1?Q?Greg_Jan=E9e?= <[EMAIL PROTECTED]> writes:
db=> explain analyze SELECT * FROM scene A WHERE A.footprint && box
'((-120.1, 34.3), (-119.7, 34.4))' ;
QUERY PLAN
---------------------------------------------------------------------
---
-------------------------------------------
Seq Scan on scene a (cost=0.00..369700.89 rows=42196 width=252)
(actual time=50.064..47748.609 rows=507 loops=1)
Filter: ((footprint)::box && '(-119.7,34.4),(-120.1,34.3)'::box)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Total runtime: 47749.094 ms
(3 rows)
This appears to be using the "box && box" operator. I'm not sure
which
operators a GIST geometry index supports, but evidently that's not one
of them. You probably want to cast the other operand differently.
How, I dunno --- the postgis lists would be a better place to ask
than here.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
