[postgis-devel] Another Data Point

Kevin Neufeld kneufeld at refractions.net
Wed Jan 21 12:23:49 PST 2009


Dancing, fun :)  It does sound like party stuff to me.
-- Kevin

Paul Ramsey wrote:
> 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
>>
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list