From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Janée <gjanee(at)alexandria(dot)ucsb(dot)edu> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: query not using index |
Date: | 2007-05-05 14:48:04 |
Message-ID: | 19323.1178376484@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
=?ISO-8859-1?Q?Greg_Jan=E9e?= <gjanee(at)alexandria(dot)ucsb(dot)edu> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Sebastian Hennebrueder | 2007-05-05 15:54:33 | Re: Feature Request --- was: PostgreSQL Performance Tuning |
Previous Message | Henrik Zagerholm | 2007-05-05 12:23:03 | Re: Query not using index despite high statistics |