On Mon, Dec 15, 2014 at 03:58:39PM +0200, Heikki Linnakangas wrote:
> >WITH closest_candidates AS (
> > SELECT
> > streets.gid,
> > streets.name,
> > streets.geom
> > FROM
> > nyc_streets streets
> > ORDER BY
> > streets.geom <->
> > 'SRID=26918;POINT(583571.905921312 4506714.34119218)'::geometry
> > LIMIT 100
> >)
> >SELECT gid, name
> >FROM closest_candidates
> >ORDER BY
> > ST_Distance(
> > geom,
> > 'SRID=26918;POINT(583571.905921312 4506714.34119218)'::geometry
> > )
> >LIMIT 1;
> >
> >See blog posts:
> >http://blog.light42.com/wordpress/?p=102
> >http://workshops.boundlessgeo.com/postgis-intro/knn.html
>
> Ugh. Ok, sold :-). I'll review...
Just to summarize, the index can only be created on the <-> operator
because that indexes on the center of the bounding box:
http://postgis.net/docs/manual-2.1/geometry_distance_centroid.html
You can't index on ST_Distance() because that computes the minimum
distance between the two objects, which is different for different
points:
http://postgis.net/docs/manual-2.1/ST_Distance.html
I am embarrassed by the LIMIT 100 hack they have to use above to find
the closest polygon to a given point, and this recheck patch is going to
fix that. I think this will remove the most significant PostGIS wart.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
