<!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.7653.38">
<TITLE>RE: [postgis-devel] Another Data Point</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>David,<BR>
Possibly. Wasn't aware of those changes. I'll check those out.<BR>
I've just recently started exploring 8.4, but haven't gotten that far into it.<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of David William Bitner<BR>
Sent: Wed 1/21/2009 1:18 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] Another Data Point<BR>
<BR>
Would any of the 8.4 implementation of the generic array_agg() function be<BR>
applicable to this?<BR>
<BR>
On Wed, Jan 21, 2009 at 11:10 AM, Obe, Regina <robe.dnd@cityofboston.gov>wrote:<BR>
<BR>
> That is not surprising. I think much of the benefit of my code was<BR>
> spoon feeding to postgis so sort of acting as a memory manager within<BR>
> the PostgreSQL context and my arrays were much smaller -- never ended up<BR>
> with a single array of yeh big as I recall. Though its been a while<BR>
> since I have looked.<BR>
><BR>
> Anyrate I'll retest in the next day or so against 3.1. I would be<BR>
> curious to see the results.<BR>
><BR>
> Yes accumulation when you get in the 1000s is non-trivial because<BR>
> PostgreSQL has to resize the array.<BR>
><BR>
> Which is why a construct such as<BR>
><BR>
> ARRAY(SELECT the_geom FROM sometable)<BR>
><BR>
> is faster than<BR>
><BR>
> SELECT ST_Accum(the_geom)<BR>
> FROM sometable<BR>
><BR>
> -----Original Message-----<BR>
> From: postgis-devel-bounces@postgis.refractions.net<BR>
> [<A HREF="mailto:postgis-devel-bounces@postgis.refractions.net">mailto:postgis-devel-bounces@postgis.refractions.net</A>] On Behalf Of Paul<BR>
> Ramsey<BR>
> Sent: Wednesday, January 21, 2009 12:05 PM<BR>
> To: PostGIS Development Discussion<BR>
> Subject: Re: [postgis-devel] Another Data Point<BR>
><BR>
> Interesting! The Shark only samples for about 20 seconds, so I only<BR>
> got the first 10% or so of the run, and the biggest user in that time<BR>
> period memcpy'ing in LWGEOM_accum (postgis) and<BR>
> advance_transition_function (pgsql). So we are spending a non-trivial<BR>
> amount of time just accumulating the input...<BR>
><BR>
> P<BR>
><BR>
> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey@cleverelephant.ca><BR>
> wrote:<BR>
> > The glove is dropped indeed... why speculate when I have the Shark...<BR>
> > time to see where our time goes...<BR>
> ><BR>
> > P<BR>
> ><BR>
> > On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis<BR>
> <mbdavis@refractions.net> wrote:<BR>
> >> Go for it, Regina! The glove is dropped...<BR>
> >><BR>
> >> Although I suspect this test may simply be running into the slower<BR>
> memory<BR>
> >> performance due to any or all of Postgres, C, GEOS compared to good<BR>
> ol'<BR>
> >> Java... Hard to beat that tuned JVM memory manager!<BR>
> >><BR>
> >> Obe, Regina wrote:<BR>
> >>><BR>
> >>> Ah I think JTS was able to do this in about 40-50 seconds. And my<BR>
> >>> version was able to beat out Kevin's nested by a small margin. I'll<BR>
> >>> retest on mine.<BR>
> >>><BR>
> >>> So I think we still need work here.<BR>
> >>><BR>
> >>> I'm curious what would happen if I combined the algorithm I wrote<BR>
> with<BR>
> >>> the new ST_Union how things would fair. In theory it should fair<BR>
> the<BR>
> >>> same, but I'm not really using Martin's cascaded union algorithm to<BR>
> the<BR>
> >>> letter.<BR>
> >>><BR>
> >>><BR>
> >>> -----Original Message-----<BR>
> >>> From: postgis-devel-bounces@postgis.refractions.net<BR>
> >>> [<A HREF="mailto:postgis-devel-bounces@postgis.refractions.net">mailto:postgis-devel-bounces@postgis.refractions.net</A>] On Behalf Of<BR>
> Paul<BR>
> >>> Ramsey<BR>
> >>> Sent: Wednesday, January 21, 2009 12:50 AM<BR>
> >>> To: PostGIS Development Discussion<BR>
> >>> Cc: lee.keel@uai.com<BR>
> >>> Subject: [postgis-devel] Another Data Point<BR>
> >>><BR>
> >>> Using the original sample set from Lee Keel,<BR>
> >>><BR>
> >>> With the old style ST_Union, 3 hours, 27 minutes:<BR>
> >>><BR>
> >>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;<BR>
> >>> st_area<BR>
> >>> --------------------<BR>
> >>> 0.0324039850011104<BR>
> >>> (1 row)<BR>
> >>><BR>
> >>> Time: 12419261.819 ms<BR>
> >>><BR>
> >>><BR>
> >>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times<BR>
> >>> faster.<BR>
> >>><BR>
> >>> uniontest=# select st_area(st_union_fast(the_geom)) from<BR>
> sample_poly;<BR>
> >>> st_area<BR>
> >>> --------------------<BR>
> >>> 0.0324039850054305<BR>
> >>> (1 row)<BR>
> >>><BR>
> >>> Time: 271618.181 ms<BR>
> >>><BR>
> >>><BR>
> >>> That's one nasty data set.<BR>
> >>><BR>
> >>> P.<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>
> >>> The substance of this message, including any attachments, may be<BR>
> >>> confidential, legally privileged and/or exempt from disclosure<BR>
> >>> pursuant to Massachusetts law. It is intended<BR>
> >>> solely for the addressee. If you received this in error, please<BR>
> >>> contact the sender and delete the material from any computer.<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>
> >> Martin Davis<BR>
> >> Senior Technical Architect<BR>
> >> Refractions Research, Inc.<BR>
> >> (250) 383-3022<BR>
> >><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>
> 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>
> 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>
--<BR>
************************************<BR>
David William Bitner<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>