[postgis/postgis] Implement ST_Distance via GEOS (#218)

[Regina Obe]

Would there be any benefit to exposing it under a different name like _ST_DistanceGeos so for cases like what strk mentioned, it could be used and also so we can more easily compare the penalty in use.

 

I recall reading somewhere that in PostgreSQL 17 they improved some of the copy logic.  I could be completely imagining that though.

 

Remember we just started the PostGIS 3.6 cycle, so now is the time to be a bit adventurous.

 

Thanks,

Regina

 

From: Paul Ramsey <pramsey at cleverelephant.ca> 
Sent: Thursday, September 26, 2024 12:07 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis/postgis] Implement ST_Distance via GEOS (#218)

 

ST_Distance native to PostGIS has a number of performance benefits that delegating to GEOS will run afoul of

 

- we can look directly at the data as stored in the database, with no copy, using getPoint_cp, that’s a performance win

- in addition to a copy overhead to get to GEOS memory space, we also pay an object instantiation penalty to construct a GEOSPoint

- for larger and disjoint objects, the native PostGIS implementation has an optimized calculation that gets cost down to O(n log(n)) time 

 

As I note in the ticket, I’m a hard -1 on tossing those advantages, unless I can be shown to be wrong about performance. Better to work the robustness stuff from first principles than to throw away the above.

 

P





On Sep 26, 2024, at 3:20 AM, Sandro Santilli <noreply at osgeo.org <mailto:noreply at osgeo.org> > wrote:

 

 

Fixes a robustness problem in Topology and doesn't trigger any
failure in existing teststsuite.

References #5782 <https://trac.osgeo.org/postgis/ticket/5782> 

 

---
View it on OSGeo Git Services: Gitea - Git with a cup of tea <https://git.osgeo.org/gitea/postgis/postgis/pulls/218> .

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20240926/35544f26/attachment.htm>