[postgis-users] diffrent execution plan on Postgres 9.5 and Postgres 11 for ST_union and performance problem Postgres 11

Paul Ramsey pramsey at cleverelephant.ca
Thu Apr 11 12:16:08 PDT 2019


something like

select encode(st_asbinary(st_collect(geom)), 'hex') from mytable where
id < 10000

just a nice hex-encoded wkb

p

On Thu, Apr 11, 2019 at 12:11 PM Martin Davis <mtnclimb at gmail.com> wrote:
>
> Yes, that's exactly the test needed.  So it looks like ST_Union(agg) on the 11 instance is much slower than on 9.5:
>
> 11: 25335.136 ms
> 9.5: 4409.919 ms
>
> The question is why...  We'll have a look and see if there's any regression in GEOS (which is what is performing the union).
>
> Are you able to share the dataset from the above test?  (As a file of WKT or WKB)
>
> On Thu, Apr 11, 2019 at 11:55 AM Lars Aksel Opsahl <Lars.Opsahl at nibio.no> wrote:
>>
>> Hi
>>
>> Do mean something like this ?
>>
>> Here is the result from postgres 11 -
>>
>> EXPLAIN ANALYZE
>>
>> select (ST_dump(st_union(geo))).geom as geo
>>
>> from sde_markslag.markslag_myrikilden_temp
>>
>> where gid  < 10000
>>
>> ;
>>
>>                                                                     QUERY PLAN
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>  Result  (cost=62634.26..62899.53 rows=1000 width=32) (actual time=25249.956..25331.325 rows=9205 loops=1)
>>
>>    ->  ProjectSet  (cost=62634.26..62639.53 rows=1000 width=32) (actual time=25249.953..25330.483 rows=9205 loops=1)
>>
>>          ->  Aggregate  (cost=62634.26..62634.28 rows=1 width=32) (actual time=25244.718..25244.719 rows=1 loops=1)
>>
>>                ->  Seq Scan on markslag_myrikilden_temp  (cost=0.00..62609.51 rows=9900 width=1593) (actual time=0.008..173.033 rows=9999 loops=1)
>>
>>                      Filter: (gid < 10000)
>>
>>                      Rows Removed by Filter: 557242
>>
>>  Planning Time: 0.064 ms
>>
>>  Execution Time: 25335.136 ms
>>
>> (8 rows)
>>
>>
>>
>> Here is the same postgres 9.5 -
>>
>> EXPLAIN ANALYZE
>>
>> [more] - > select (ST_dump(st_union(geo))).geom as geo
>>
>> [more] - > from sde_markslag.markslag_myrikilden_temp
>>
>> [more] - > where gid  < 10000
>>
>> [more] - > ;
>>
>>                                                                QUERY PLAN
>>
>> ----------------------------------------------------------------------------------------------------------------------------------------
>>
>>  Aggregate  (cost=170462.27..170467.28 rows=1000 width=1604) (actual time=4311.911..4409.250 rows=9205 loops=1)
>>
>>    ->  Seq Scan on markslag_myrikilden_temp  (cost=0.00..170437.51 rows=9903 width=1604) (actual time=0.054..629.045 rows=9999 loops=1)
>>
>>          Filter: (gid < 10000)
>>
>>          Rows Removed by Filter: 557242
>>
>>  Planning time: 0.045 ms
>>
>>  Execution time: 4409.919 ms
>>
>> (6 rows)
>>
>>
>>
>> Thanks
>>
>> Lars
>>
>> ________________________________
>> From: postgis-users <postgis-users-bounces at lists.osgeo.org> on behalf of Martin Davis <mtnclimb at gmail.com>
>> Sent: Thursday, April 11, 2019 8:07 PM
>> To: PostGIS Users Discussion
>> Subject: Re: [postgis-users] diffrent execution plan on Postgres 9.5 and Postgres 11 for ST_union and performance problem Postgres 11
>>
>>
>>
>> On Thu, Apr 11, 2019 at 3:27 AM Lars Aksel Opsahl <Lars.Opsahl at nibio.no> wrote:
>>
>> Can it be problem related ST_Union and aggregate ?
>>
>>
>> Can you test the performance of aggregate ST_Union on it's own by dropping the GROUP BY and instead using a WHERE clause to union a small-ish subset of the geometries?  (But large enough to give a measurable query time.)
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-users
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-users


More information about the postgis-users mailing list