I have a simple SQL statement for computing the Hausdorff distance between two polygons of the form:
SELECT ST_HausdorffDistance(geom1, geom2);
, which is taking a long time (for a pair of polygons with a little over 1000 vertices each). The full query (in WKT: https://pastebin.com/ndyxE0aD) takes almost 5 seconds on a computer with Intel i9 CPU (PostgreSQL 11/PostGIS 2.5 on GEOS 3.7.2).
I needed to do this computation many times to compute Hausdorff distances between all features from two polygon tables, each with about 100 features. (The pasted example are the first records in each table). The query took 3.5 hours for such a small dataset. Similar queries on much larger road tables (with 500 to 1000 features in each table) took less than a minute.
I was wondering why the ST_HausdorffDistance computation is slow on the polygon data?
Is it because of an implementation issue or bug of PostGIS or the GEOS function behind it? Or is there something wrong with the polygon data I use?
Has anyone had similar issues with the polygon Hausdorff distance?
-- Update --
I only used
time command from shell to test the times. As pointed out in the comments, the actual CPU time isn't bad at all.
For one run, the
sys time are 4.6, 0.05, 0.01 seconds respectively. For a larger run involving two datasets of similar polygons (but with data directly read from database, not from
ST_GeomFromEWKT), it's 138m8s, 0.2 s, 0.05 s, respectively. So the CPU time is indeed small.
The GEOS package is compiled from source:
CXXFLAGS=-std=c++17 ./configure --prefix /opt/geos --enable-python make && sudo make uninstall && sudo rm -rf /opt/geos && sudo make install
My new question is:
Why is the
real time (wall time) so long compared to CPU time? (I have a SSD.) and how to configure PostgreSQL to reduce the wall time?