[postgis-devel] Another Data Point

Wed Jan 21 11:50:55 PST 2009

Now can I do my little dance?

uniontest=# SELECT geometrytype(_unite_garray_fast(ARRAY(SELECT
the_geom FROM sample_poly)));
 geometrytype
--------------
 MULTIPOLYGON
(1 row)

Time: 24122.901 ms
uniontest=#

On Wed, Jan 21, 2009 at 11:43 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Paul,
> I wouldn't proclaim victory on that alone.
>
> Do another test.  20 seconds sounds a little too short.
> I'm not saying it isn't right and my memory may be wrong on the JTS result
> too.
> Besides JTS would have to collect geometries as well I imagine so you can't
> simply throw that out and proclaim victory.
>
>
> Test out
>
> SELECT geometrytype(st_unite_garray(ARRAY(SELECT the_geom FROM
> sample_poly)))
>
> Though that wouldn't be quite a true test either. But somewhere between the
> two would be the answer.
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
> Sent: Wed 1/21/2009 1:58 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Another Data Point
>
> Well, just running this:
>
> uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
>   geometrytype
> --------------------
>  GEOMETRYCOLLECTION
> (1 row)
>
> Time: 261624.195 ms
>
> takes 251 of the 271 seconds the union operation took... the
> implication is that the GEOS portion of the work is on the order of 10
> seconds.
>
> P.
>
> On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis <mbdavis at refractions.net>
> wrote:
>> Could be...   It would be interesting to see whether GEOS is faster than
>> JTS.   Needs a test environment able to run both pieces of code on the
>> same
>> hardware.
>>
>> Paul Ramsey wrote:
>>>
>>> I got another run in, right near the end, and it showed that
>>> GEOSUnionCascaded took only about 50% of the time in that slice. There
>>> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
>>> would be as fast as JTS (or faster?).
>>>
>>> P.
>>>
>>> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>> wrote:
>>>
>>>>
>>>> Interesting! The Shark only samples for about 20 seconds, so I only
>>>> got the first 10% or so of the run, and the biggest user in that time
>>>> period memcpy'ing in LWGEOM_accum (postgis) and
>>>> advance_transition_function (pgsql). So we are spending a non-trivial
>>>> amount of time just accumulating the input...
>>>>
>>>> P
>>>>
>>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>>> wrote:
>>>>
>>>>>
>>>>> The glove is dropped indeed... why speculate when I have the Shark...
>>>>> time to see where our time goes...
>>>>>
>>>>> P
>>>>>
>>>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Go for it, Regina!  The glove is dropped...
>>>>>>
>>>>>> Although I suspect this test may simply be running into the slower
>>>>>> memory
>>>>>> performance due to any or all of Postgres, C, GEOS compared to good
>>>>>> ol'
>>>>>> Java...  Hard to beat that tuned JVM memory manager!
>>>>>>
>>>>>> Obe, Regina wrote:
>>>>>>
>>>>>>>
>>>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>>>>> retest on mine.
>>>>>>>
>>>>>>> So I think we still need work here.
>>>>>>>
>>>>>>> I'm curious what would happen if I combined the algorithm I wrote
>>>>>>> with
>>>>>>> the new ST_Union how things would fair.  In theory it should fair the
>>>>>>> same, but I'm not really using Martin's cascaded union algorithm to
>>>>>>> the
>>>>>>> letter.
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>>>>>> Paul
>>>>>>> Ramsey
>>>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>>>>> To: PostGIS Development Discussion
>>>>>>> Cc: lee.keel at uai.com
>>>>>>> Subject: [postgis-devel] Another Data Point
>>>>>>>
>>>>>>> Using the original sample set from Lee Keel,
>>>>>>>
>>>>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>>>>
>>>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>>>>     st_area
>>>>>>> --------------------
>>>>>>>  0.0324039850011104
>>>>>>> (1 row)
>>>>>>>
>>>>>>> Time: 12419261.819 ms
>>>>>>>
>>>>>>>
>>>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>>>>> faster.
>>>>>>>
>>>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>>>>>>     st_area
>>>>>>> --------------------
>>>>>>>  0.0324039850054305
>>>>>>> (1 row)
>>>>>>>
>>>>>>> Time: 271618.181 ms
>>>>>>>
>>>>>>>
>>>>>>> That's one nasty data set.
>>>>>>>
>>>>>>> P.
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>> -----------------------------------------
>>>>>>> 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.
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Davis
>>>>>> Senior Technical Architect
>>>>>> Refractions Research, Inc.
>>>>>> (250) 383-3022
>>>>>>
>>>>>> _______________________________________________
>>>>>> postgis-devel mailing list
>>>>>> postgis-devel at postgis.refractions.net
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>
>>>>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
> ________________________________
>
> 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.
>
> ________________________________
>
> Help make the earth a greener place. If at all possible resist printing this
> email and join us in saving paper.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>