<br><font size=2 face="sans-serif">Greetings postgis-ers,</font>
<br>
<br><font size=2 face="sans-serif">We have a need to rapidly sift through
a pile of points, and the Rtree implementation is slower than our timelines
will allow. We are exploring mutliple pathways to enhancing our performance,
including creating a indexed geohash column with ST_geohash(). "Ok",
but not "great".</font>
<br>
<br><font size=2 face="sans-serif">However, there are tantilizing references
in the mailing list to improved performance for points using space partitioning
schemes. In particular, I refer to Paul Ramsay's message of a year ago,
where he said: </font>
<br>
<br><font size=2 face="sans-serif">Nearest neighbor, as Stephen notes in
the followup is not something</font>
<br><font size=2 face="sans-serif">that is necessarily easy in general.
However! Another development</font>
<br><font size=2 face="sans-serif">on-stream for PostgreSQL 8.5 will allow
us to both (a) use k-d tree</font>
<br><font size=2 face="sans-serif">indexes for points, which are much more
efficient and (b) to do</font>
<br><font size=2 face="sans-serif">nearest-neighbor searching using the
index tree, which will be a great</font>
<br><font size=2 face="sans-serif">deal more optimal for general cases.</font>
<br>
<br><font size=2 face="sans-serif">(</font><a href="http://www.mail-archive.com/postgis-users@postgis.refractions.net/msg08026.html"><font size=2 face="sans-serif">http://www.mail-archive.com/postgis-users@postgis.refractions.net/msg08026.html)</font></a>
<br>
<br><font size=2 face="sans-serif">I now note that PostgreSQL 8.5 and PostGIS
1.5 have been released, so I would like to follow up on this topic to see
if k-d trees have in fact been implemented, or, if not, how one might start
such an approach (perhaps a topic for the dev list). </font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Bryce</font>