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)