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

Paul Ramsey pramsey at cleverelephant.ca
Thu Sep 26 09:52:25 PDT 2024



> On Sep 26, 2024, at 9:49 AM, Regina Obe <lr at pcorp.us> wrote:
> 
> 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.

Well, we can do that in a PR, and strk’s PR here just does the same idea only by retaining a ST_Distance_LWGeom, so he can performance test his branch. 

>  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.

We do have lots of time to fix things! Fixing the precision issues would be back-portable though, while changing the implementation to a GEOS back-end, probably not.

P

>  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> wrote:
>>   Fixes a robustness problem in Topology and doesn't trigger any
>> failure in existing teststsuite.
>> References #5782
>>  ---
>> View it on OSGeo Git Services: Gitea - Git with a cup of tea.




More information about the postgis-devel mailing list