- Shipped
- 19 Agosti 2026, 16:19 UTC
- Author
- Kamo
- Commit
- 9b3ad2c
/api/send took 1.8-7.9 s for most addresses and single-digit ms for a few, which is not a load problem — it is the shape of the geolite query. getLocation() is awaited before the event is written, so that latency was paid by the browser on every tracked event, and on the marketing site it was paid twice over because the tracker awaits the beacon before navigating. WHERE network_start <= $1 AND network_end >= $1 ORDER BY network_start DESC LIMIT 1 reads as an index seek and is not one. With idx_geolite_blocks_range_asc the planner walks the index backwards from the address and hands each row to the filter. The blocks are non-overlapping and ordered, so the only row that can ever match is the first one visited — and when that row's range ends below the address (an unallocated range, or any address past the end of a block) every earlier row fails the same test, so the scan runs to the start of a 5.8M-row table before returning nothing. Seeking to that single candidate first and testing network_end afterwards returns exactly the same rows. Measured against the live table: 47.181.8.84 1807 ms -> 7 ms US 208.67.222.222 7871 ms -> 5 ms US 93.184.216.34 4441 ms -> 6 ms US 203.0.113.7 7193 ms -> 6 ms (no match, correctly) No schema change: the index this needs already exists. Also drops the 26257 port fallback. CockroachDB is retired but that port still answers, so a GEO_DATABASE_URL without an explicit port would connect happily and then fail to find the tables rather than refusing outright.