jiayuasu opened a new issue, #2940: URL: https://github.com/apache/sedona/issues/2940
Follow-up to the spatial join planner work for Box2D (sibling of the issue that adds Box2D-aware join detection). ## Scope Today Sedona's R-tree spatial index keys on JTS `Envelope` objects derived from `Geometry`. When joining two `Box2D` columns, the index path still goes through Envelope construction — an unnecessary allocation and a JTS dependency on a hot loop. This issue tracks adding a specialized R-tree (or adapting the existing one) that indexes `Box2D` directly: 4 doubles, no JTS detour. ## When to do this **Only after the spatial join planner work lands** (the issue that adds `ST_BoxIntersects` / `ST_BoxContains` join detection) and **only if profiling shows the JTS Envelope construction is a real cost.** The slow path (Box2D → Envelope → existing R-tree) gives correct results today; this issue is purely an optimization. Order: ship correctness first, optimize second. ## Implementation sketch - Either a new R-tree implementation parameterized over `Box2D`, or a thin adapter that reuses the existing internal structure but skips the `Envelope` round-trip on insert / query. - Benchmark vs the existing path on real workloads (large bbox tables, range queries). - Pick the path that's cleaner — full reimplementation only if the adapter ends up hacky. ## Out of scope - API changes to the spatial join planner — it should be transparent to whether the index is Box2D-keyed or Envelope-keyed. - Index types other than R-tree. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
