Re: query not using index

From: Greg Janée <gjanee(at)alexandria(dot)ucsb(dot)edu>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: query not using index
Date: 2007-05-07 16:05:20
Message-ID: 82B0CEED-34B4-430A-ADFE-445EE7A4659D@alexandria.ucsb.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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?= <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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-05-07 16:07:03 Re: Any "guide to indexes" exists?
Previous Message Tom Lane 2007-05-07 16:03:20 Re: linux bug and lost rows