perf(rust): point-coordinate fast paths for ST_Distance/ST_DWithin/ST_Azimuth

[james-willis]

Introduces PointXYGeometryFactory (in sedona-functions): a GeometryFactory whose Geom is a PointOrWkb — a finite Point decoded straight from its fixed WKB offset (no full parse), or a parsed Wkb for anything else (incl. POINT EMPTY). Because GenericExecutor parses each scalar once, kernels built on it get parse-once-for-scalars for free. Replaces the hand-rolled PreparedScalar scalar-prep that was here before.

Adopted in the planar point-coordinate distance functions:

• ST_Distance — Point/Point computes Euclidean directly; mixed Point/geometry uses a geo_types::Point so the Point is never re-parsed.
• ST_DWithin — shares ST_Distance's backend (distance <= bound); this also speeds the spatial-join distance predicate transitively.

Results vs main (criterion):

config	ST_Distance	ST_DWithin
Array/Array Point,Point	−68%	−63%
Array/Scalar Point,Point	−67%	—
Array Point / Scalar Polygon	−41%	−33%
Array Polygon / Scalar Point	−24%	—
Array/Array Point,Polygon	−34%	—

(The mixed Point/geometry cases improve too, since the factory computes point-to-geometry without re-parsing the Point.)

ST_Azimuth applies the same "skip the parse for points" idea but lands on the lighter primitive. It is defined only for two non-empty POINTs (non-Point and POINT EMPTY are errors, not a fallback), so it is coordinate-extraction-shaped rather than a distance kernel: it reads each operand's (x, y) via read_point_xy on a WkbBytesExecutor — no parse, no enum. Benchmarked head-to-head against the factory, the accessor wins the dominant two-point-column shape:

ST_Azimuth config	accessor vs main	accessor vs factory
Array/Array Point,Point	−40%	~8% faster
Array/Scalar Point,Point	−14%	~8% slower
Scalar/Array Point,Point	−15%	~8% slower

Both variants beat the full-parse baseline everywhere; the accessor is chosen for the ArrayArray win (the largest absolute saving and the canonical origin→destination shape) and to keep the split consistent — accessors read via read_point_xy, distance/fallback kernels use the factory.

ST_X / ST_Y are deliberately left on their existing read_point_xy fast path. Migrating them to the factory regressed them ~30% in benchmarks: the PointOrWkb enum (sized to its Wkb variant) adds per-element overhead that, for the already-optimal unary case, isn't offset by any parse savings. So the factory is the right tool for the binary distance kernels but not for the unary accessors.

Geography distance/dwithin/maxdistance (s2geography) are a separate follow-up.

[paleolimbot]

Cool!

I know you're still working here, but we have something called a GeometryFactory (parameterized by executor) that might be a good fit here...it handles the "preparation" of scalars to ensure we don't parse WKB more than needed. Maybe a PointXYGeometryFactory / GenericExecutor<PointXYGeometryFactory> would make this trivial to scale out to other places.

[paleolimbot]

Thank you!

The low level WkbPointLayout would benefit from a quick test covering the type of points it supports (especially errors resulting from incomplete buffers, including EWKB), with apologies if I missed this test.

[paleolimbot]

This is great!

Because it's doing some byte parsing / is indexing into buffers in a way that could panic for an out of bounds read, I think it needs at least one test to cover the branches. Hopefully there are some in this file to draw from (if not, there are some fixtures in sedona-testing).