fix(postgres): let distanceLessThan use the spatial index

[HarshMN2345]

What does this PR do?

distanceLessThan compiled to ST_Distance(...) < :distance. PostGIS cannot answer that from a GIST index, so a radius query filtered every row while walking the primary key, and got slower the fewer rows matched (appwrite/appwrite#14177).

• Without meters: ST_DWithin(col, geom, :distance) AND ST_Distance(col, geom) < :distance. ST_DWithin uses the index; ST_Distance keeps the boundary exclusive.
• With meters, point column and point value: col && ST_Expand(geom, :lon, :lat) AND <unchanged geography ST_Distance>. The box holds every point within range on the WGS84 spheroid: a degree of latitude spans at least 110,574 m, and a degree of longitude at least 111,319 m × cos of the most poleward latitude in range.
• Unchanged SQL (exact geography comparison only): lines and polygons on either side, since their geodesic edges bulge out of any planar box, and boxes that would reach a pole or the antimeridian.
• distanceGreaterThan, distanceEqual and distanceNotEqual are unchanged; they cannot use an index.

Test Plan

200,000 points in the issue's layout (~700 × 900 km around [10, 51]) on PostgreSQL 18 + PostGIS 3.6 with the spatial index, limit 25, average of 20 runs:

Query	Before	After
1 km, meters	188 ms (pkey scan, 199,997 rows removed by filter)	1.2 ms (GIST index scan)
20 km, meters	13.6 ms	1.6 ms
1 km in degrees	30 ms	0.8 ms

Each query returns the same rows as before.

Results were also compared with the old SQL on 100,000 points packed near both poles and the antimeridian. 800 random meter queries (10 m to 1,000 km, half of them centered near a pole or the antimeridian) returned identical rows. Cases that drop rows under a naive degree radius also match: 1 m around [0, 89.999], a point 20 km from the geodesic arc of [[-60, 60], [60, 60]], and a stored line within 20 km of a point.

tests/e2e/Adapter/PostgresTest.php and tests/e2e/Adapter/SharedTables/PostgresTest.php pass. No new test: which plan Postgres picks is not observable through the adapter API, and the existing spatial e2e tests cover the results.

Related

• 🐛 Bug Report: Distance queries never use the spatial index appwrite/appwrite#14177
• fix(databases): use the spatial index for distance queries appwrite/appwrite#14199

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 18 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository: utopia-php/database/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: d2dc84c9-d71f-498d-87fd-163967e93746

📥 Commits

Reviewing files that changed from the base of the PR and between ef5d6e5 and c5fc677.

📒 Files selected for processing (1)

• src/Database/Adapter/Postgres.php

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}