Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Use GeoHash ordering instead of way ordering #242
Creating a table as ORDER BY way is known to offer no performance advantages (#87) and in fact ahve losses in some cases.
Rather than simply doing an order on
The polygons table from planet-130904.osm.pbf was used, and a new table created.
CREATE TABLE polygon_test AS SELECT * FROM planet_osm_polygon ORDER BY ST_GeoHash(ST_Transform(ST_Envelope(way),4326),<N>);
Base time of
There is a theoretical basis for preferring a geohash with an even number of characters, which this is.
Interesting and strange result at the same time.
I did a quick test yesterday on a small extract (to limit other side effects like I/O) and the 6 chars ST_Geohash were faster than the 8 chars one in my test. My test was not the same, I simply created a Geohash based index later used by CLUSTER.
Maybe a side effect on the CREATE TABLE / SELECT / ORDER BY due to much more similar values ?
You really need to make sure that you're hitting disk. An in-memory sort is a different beast from a disk-based sort.
I wouldn't be surprised if the CLUSTER case had difference performance characteristics, but without details I can't really comment.
added a commit
this pull request
Dec 31, 2014
Dec 31, 2014
1 check passed
i just tried an import using 0.87.2-dev on postgres 9.1 with enabled slim-mode, hstore and flatnodes and got the following error:
A switchback to 0.87.1 solves the problem.
It seems to depend on the data. Planet, Germany and Hesse crashed. Some other smaller areas passed without error. So you best test with Hesse file if you like to reproduce the error (http://download.geofabrik.de/europe/germany/hessen.html).