Opened 8 months ago

Closed 3 months ago

#5692 closed enhancement (worksforme)

Speed up ST_Distance/ST_ClosestPoint/ST_ShortestLine

Reported by: strk Owned by: pramsey
Priority: medium Milestone: PostGIS 3.5.0
Component: postgis Version: master
Keywords: Cc:

Description

The time it takes to find the closest segments from big inputs is pretty big at the moment.

For the input cases attached to ticket #3587 it is 23 seconds:

=# select ST_Length(ST_ShortestLine(a.geom, b.geom)) from test10input_singlepoly a, test10input_singlepoly b where a.path = 0 and b.path = 386;
       st_length       
-----------------------
 0.0001389923653910171
(1 row)

Time: 23802.062 ms (00:23.802)
=# select ST_Distance(a.geom, b.geom) from test10input_singlepoly a, test10input_singlepoly b where a.path = 0 and b.path = 386;
      st_distance      
-----------------------
 0.0001389923653910171
(1 row)

Time: 24588.245 ms (00:24.588)
=# select st_npoints(a.geom) na, st_npoints(b.geom) nb from test10input_singlepoly a, test10input_singlepoly b where a.path = 0 and b.path = 386;
   na   |  nb  
--------+------
 118852 | 6665
(1 row)

Looking at the code there's a square root computation for each pair taken in consideration, we should at least take that square root out.

An initial movement in that direction was undertaken for topology some time ago so we now do have a ptarray_closest_segment_2d which avoids the sqrt() call, but it's not used much.

Change History (1)

comment:1 by pramsey, 3 months ago

Resolution: worksforme
Status: newclosed

I ran some tests of sqrt vs not and could not find measurable performance differences. Not sure what that means, maybe just that there is an overhead but it is small in relation to everything else, to the point it is not measurable.

Note: See TracTickets for help on using tickets.