You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sedona.apache.org by "Kristin Cowalcijk (Jira)" <ji...@apache.org> on 2022/12/02 11:10:00 UTC

[jira] [Created] (SEDONA-206) Severe performance regression of ST_Transform

Kristin Cowalcijk created SEDONA-206:
----------------------------------------

             Summary: Severe performance regression of ST_Transform
                 Key: SEDONA-206
                 URL: https://issues.apache.org/jira/browse/SEDONA-206
             Project: Apache Sedona
          Issue Type: Bug
            Reporter: Kristin Cowalcijk
             Fix For: 1.3.0
         Attachments: image-2022-12-02-18-55-39-236.png

The performance of ST_Transform drastically degraded since 1.3.0. This is the flamegraph of an executor node when running queries like this:

{code}
SELECT COUNT(1) FROM ms_buildings WHERE ST_Transform(ST_FlipCoordinates(geom), 'epsg:4326', 'epsg:3857') is not NULL
{code}

 !image-2022-12-02-18-55-39-236.png! 

The performance regression is caused by the introduction of custom CRS support. As we can see, most of the time was spent by exception handlers in geotools-referencing module. It is a very common use case to specify a well known CRS when calling ST_Transform, and we don't want to suffer from such a performance hit when doing that. One approach to fix this problem is to detect if the CRS string "looks like" a well known CRS by pattern matching before calling the expensive {{CRS.parseWKT}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)