[PostGIS] #5692: Speed up ST_Distance/ST_ClosestPoint/ST_ShortestLine

[PostGIS]

#5692: Speed up ST_Distance/ST_ClosestPoint/ST_ShortestLine
-------------------------+---------------------------
 Reporter:  strk         |      Owner:  pramsey
     Type:  enhancement  |     Status:  new
 Priority:  medium       |  Milestone:  PostGIS 3.5.0
Component:  postgis      |    Version:  master
 Keywords:               |
-------------------------+---------------------------
 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.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5692>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.