Opened 11 years ago
Last modified 2 months ago
#2614 new enhancement
Prepared geometry support for ST_DWithin
Reported by: | robe | Owned by: | pramsey |
---|---|---|---|
Priority: | high | Milestone: | PostGIS Fund Me |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description (last modified by )
In some cases, despite what we tell people, doing an
ST_Intersects(geom1, ST_Buffer(geom2,radius))
is sometimes faster than ST_DWithin(geom1,geom2, radius)
Granted ST_DWithin is more accurate.
I'll come up with a small self-standing example to demonstrate the point. The one I have currently is kind of hefty.
But basic assumption is if you have a fairly large constant geometry then ST_Intersects(ST_Buffer..) often out performs ST_DWithin. I assume this is because ST_Intersects takes advantage of prepared geometries and ST_DWithin does not.
Change History (15)
comment:1 by , 11 years ago
Description: | modified (diff) |
---|
comment:2 by , 10 years ago
comment:3 by , 10 years ago
Priority: | medium → high |
---|
comment:4 by , 9 years ago
Milestone: | PostGIS 2.2.0 → PostGIS 2.3.0 |
---|
comment:6 by , 8 years ago
Milestone: | PostGIS 2.3.0 → PostGIS 2.4.0 |
---|
comment:7 by , 7 years ago
Milestone: | PostGIS 2.4.0 → PostGIS 2.5.0 |
---|
comment:10 by , 6 years ago
Milestone: | PostGIS 2.5.0 → PostGIS next |
---|
comment:12 by , 5 years ago
Milestone: | PostGIS 3.0.0 → PostGIS Fund Me |
---|
comment:13 by , 10 months ago
For the record: GEOS-3.10 (2021-10-20) added GEOSDistanceWithin and GEOSPreparedDistanceWithin and I know they are both much faster than the current lwgeom_mindist2d_tolerance implementation ( see https://trac.osgeo.org/postgis/ticket/3587#comment:45 )
comment:14 by , 10 months ago
Still for the record: GEOSDistanceWithin is also faster when I force the use of the so called "fast" distance calculation in PostGIS, for the case of a large ring compared against a ring inside of it.
comment:15 by , 2 months ago
Note you cannot test one gnarly case and call all things faster. At a minimum, point/point distance will be worse, because of the marshalling cost for GEOS. Also true no doubt of all kinds of small feature→small feature cases. Great care is required to muck with the distance functions because they drive so many of the use cases.
This is my distance rect-tree improvement, which is still sitting half-done, taunting me… it scares me too, since distance is only 95% of what people do all the time. Mucking with it is scary.