[SEDONA-189] Prepare geometries in broadcast join

[tanelk]

Did you read the Contributor Guide?

• Yes, I have read Contributor Rules and Contributor Development Guide

Is this PR related to a JIRA ticket?

• Yes, the URL of the assoicated JIRA ticket is https://issues.apache.org/jira/browse/SEDONA-189. The PR name follows the format [SEDONA-189] my subject.

What changes were proposed in this PR?

Use prepared geometries in BroadcastIndexJoinExec to speed up queries. In jira there is a simple dataset of polygons and points, where the speedup is around 4x.

Preparing the geometry has some overhead, but it will be compensated if the prepared geometry will be used several times. Using it in broadcast join seems like a safe bet - the broadcasted dataset is meant to be small.

How was this patch tested?

Running the existing UTs in sql submodule

Did this PR include necessary documentation updates?

• No, this PR does not affect any public API so no need to change the docs.

[jiayuasu]

@umartin Hi Martin, is this PreparedGeometry related to your https://issues.apache.org/jira/browse/SEDONA-178 ?

[tanelk]

@umartin Hi Martin, is this PreparedGeometry related to your https://issues.apache.org/jira/browse/SEDONA-178 ?

That seems like an unrelated issue.

PreparedGeometry is a tool in JTS that can speed up spatial predicates (contains, crosses, etc..). It does not directly impact distance queries and does not change impact correctness - performance only.

[umartin]

@umartin Hi Martin, is this PreparedGeometry related to your https://issues.apache.org/jira/browse/SEDONA-178 ?

That seems like an unrelated issue.

PreparedGeometry is a tool in JTS that can speed up spatial predicates (contains, crosses, etc..). It does not directly impact distance queries and does not change impact correctness - performance only.

I agree. It only impacts performance. I was just going off on a tangent when discussing refactoring spatial partitioning code. That might have caused some confusion