[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