<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [postgis-devel] More Cascade Union Adventures</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Thanks Webb,<BR>
<BR>
Unfortunately I'm not sure how to figure out the array size as the aggregate is forming - since it doesn't seem I can get a count while its counting.<BR>
<BR>
On the bright-side for most use cases, I don't think the penalty is that bad. This was a test with I think 30,000 small polygons so in most cases rare.<BR>
<BR>
For example running my same exercise on Massachusetts towns which has 351 records total - these are the results I get. These are fairly large polygons but only 351 cycles vs. the 30,000 small polys (30,000 cycles) I was testing earlier. to me 52 secs vs. 56 secs is not that much to cry about. Still way better than 585,482 ms of the default ST_Union. <BR>
<BR>
In this case JTS wins by quite a margin - and finishes in 16 secs. I presume because there is no way to optimize for the fact that Geos just doesn't deal with large memory as well as JTS and also I am not taking into consideration the size of the polys. So large polys JTS I'm guessing will win unless I take into consideration the area of each poly starting out which may add more overhead than it is worth.<BR>
<BR>
--351 records<BR>
--52,983 ~ 52 secs<BR>
SELECT st_unitecascade_garray_sort(ARRAY(SELECT the_geom from towns))<BR>
<BR>
--56,748 ms ~ 56 secs<BR>
SELECT ST_CascadeUnion(the_geom)<BR>
FROM towns<BR>
<BR>
--585,482 ms. - 10 minutes<BR>
SELECT ST_Union(the_geom)<BR>
FROM towns<BR>
<BR>
Open Jump JTS 1.9.0 - 16 secs<BR>
<BR>
Thanks,<BR>
Regina<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Webb Sprague<BR>
Sent: Wed 8/13/2008 12:59 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] More Cascade Union Adventures<BR>
<BR>
, but evidentally the array accum calls give a major<BR>
>> penalty.<BR>
<BR>
I can't add much to this discussion, but if you know how large your<BR>
array will be, there is now an operation to preallocate it (array_fill<BR>
or some such). Should be google-able.<BR>
<BR>
-W<BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
The substance of this message, including any attachments, may be confidential, legally privileged and/or exempt from disclosure pursuant to Massachusetts law. It is intended solely for the addressee. If you received this in error, please contact the sender and delete the material from any computer.
</STRONG></P></BODY></HTML>
<P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>