Hey, I think you misunderstood me, of course array of geom are not a replacement of proper use of aggregate. It's just that in some case you cannot do with aggregate and array function are very usefull, or the only solution. (example : WITH A AS (
) for instance when 2014-09-01 14:39 GMT+02:00 Paragon Corporation <[email protected]>: > > > > > What I target is not the unioning between the layers but inside the > same layer. The problem is the same -> to do something with more than two > geometries involved. > > > > Adding aggregates is really less a priority than adding support for > > > ARRAY[geom1,geom2,geom3...] for the relevant functions. > > > > Are you sure that the planner and indexes will manage arrays better? > > The reason I was thinking an array of aggregates is not as useful as an > ST_Intersection aggregate is that as you intersect geometries you are using > less memory rather than more > with array you'd have to accumulate them first. > > It really is a sequential thing. > > That is not to say the ARRAY version isn't useful, but if you have a bunch > of geometries and then have to array them to get an intersection, then it > would be slower. > I could be wrong on that of course. Paul and Nicklas can correct me on > that since they are more familiar with the innards. > > I have on occasion come into the situation where the things I want to get > intersection of are in separate rows rather than separate layers and it is > a tad bit annoying to work around it. Doesn't come up often though. > > Now with 9.4 coming with the FILTER syntax now makes the across rows much > easier if I actually had an ST_Intersection aggregate that could take > advantage of it. > > > Yes, I guess you are right that it would be possible to write a > function that does the job from a collection > > > But the function will have to do the same thing. To calculate a > result from 2 polygons, then use the resulting polygon for calculation > against the third polygon and so on. Just like an aggregate function works. > > I actually hadn't thought of our ST_UnaryUnion > http://postgis.net/docs/manual-2.1/ST_UnaryUnion.html equivalent of > ST_Intersection which is what I think Nicklas is talking about here. That > would be useful as well. > That introduces another question though? > > Would an ST_Intersection aggregate double as an ST_UnaryIntersection? > or we just keep them separate. > > I would say keep them separate so that we have a parallel with > ST_UnaryUnion and also you can use it NOT as an aggregate to satisfy the > array like need. > > > > Thanks, > Regina > > > > _______________________________________________ > postgis-users mailing list > [email protected] > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users >
_______________________________________________ postgis-users mailing list [email protected] http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
