From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dan Harris <fbsd(at)drivefaster(dot)net>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Help optimizing a slow index scan |
Date: | 2006-03-18 05:29:41 |
Message-ID: | 20060318052941.GA46733@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Mar 17, 2006 at 11:41:11PM -0500, Tom Lane wrote:
> Dan Harris <fbsd(at)drivefaster(dot)net> writes:
> > Furthermore, by doing so, I am tying my queries directly to
> > "postgres-isms". One of the long term goals of this project is to be
> > able to fairly transparently support any ANSI SQL-compliant back end
> > with the same code base.
>
> Unfortunately, there isn't any portable or standard (not exactly the
> same thing ;-)) SQL functionality for dealing gracefully with
> two-dimensional searches, which is what your lat/long queries are.
The OpenGIS Simple Features Specification[1] is a step in that
direction, no? PostGIS[2], MySQL[3], and Oracle Spatial[4] implement
to varying degrees. With PostGIS you do have to add non-standard
operators to a query's predicate to benefit from GiST indexes on
spatial columns, but the rest of the query can be straight out of
the SQL and OGC standards.
[1] http://www.opengeospatial.org/docs/99-049.pdf
[2] http://www.postgis.org/
[3] http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html
[4] http://www.oracle.com/technology/products/spatial/index.html
--
Michael Fuhr
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2006-03-18 08:50:48 | Re: Help optimizing a slow index scan |
Previous Message | Tom Lane | 2006-03-18 04:41:11 | Re: Help optimizing a slow index scan |