вт, 10 июл. 2018 г. в 12:48, Pavan Deolasee <[email protected]>:
> > On Tue, Jul 10, 2018 at 12:22 PM, Darafei "Komяpa" Praliaskouski < > [email protected]> wrote: > >> >> What you can try is to short-circuit ST_Expand to ST_Buffer for now. It's >> more expensive computationally, but for most practical use cases the box it >> produces should be similar to that of ST_Expand, and serialized geometry >> should produce the same box on both sides of serialization. >> >> > > Thanks for the tip. That seems to do the trick. Apart from the performance > impact, can this cause any regression? > ST_Intersects(ST_Buffer()) is different from ST_Within() on the edge, by <1%. ST_Buffer on geography is actually ST_Buffer on plane, so for long geometries there are bigger error margins. Anything on the scale of city / buildings should be fine. > FWIW PostGIS regression tests does not show any new failure, but anything > specific I should test? > Test whether you can replace ST_DWithin(a, b, eps) with ST_Intersects(ST_Buffer(a, eps), b). > With regard to performance impact, could it be material? And if so, in > what circumstances? > You're replacing O(N) with somewhat like O(NlogN). ST_Expand output size is O(N), ST_Buffer's is up to O(4*N*quad_segs), where quad_segs is usually 8. A scenario with massive regression I see: you have a city polygon and want all buildings in it while your db holds just that city and a bit around. This way you calculate and throw away a buffer for every building in that city. A scenario with almost no regression: you have a GPS position of someone and want to get shops within N meters around them. You buffer their point once, select some small amount of shops around and buffer only them (as ST_DWithin buffers both sides). > > Thanks, > Pavan > > -- > Pavan Deolasee http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > _______________________________________________ > postgis-users mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/postgis-users
_______________________________________________ postgis-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/postgis-users
