[openstreetmap/openstreetmap-website] Serve only trackable and identifiable points and add cursor pagination to the trackpoints API (PR #7322)

Ruben L. Mendoza notifications at github.com
Wed Sep 16 23:13:33 UTC 2026


Rub21 left a comment (openstreetmap/openstreetmap-website#7322)

 Thanks for running it. If I read the plan right, it walks the whole gpx_id index (2.6 TB) because the planner picks it for the merge join with gpx_files, and it never touches the tile index. I am not sure why, I made two requests to the production API with the same bbox and the current query takes about 10 seconds per page:

```bash
 curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" "https://api.openstreetmap.org/api/0.6/trackpoints?bbox=40.10,55.95,40.60,56.45&page=0"
 200 11.68s
 curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" "https://api.openstreetmap.org/api/0.6/trackpoints?bbox=40.10,55.95,40.60,56.45&page=5"
 200 9.81s
``` 

Maybe the OFFSET 0 subquery is the wrong approach here :( 

The plan also shows the real limit, I think this bbox has 5.1 million points, and every page has to read all of them again. Even with the tile index a page would not be faster as we want,  I think it is fine to focus on the tracks PR (#7348) first and build the pagination on top of gpx_tracks.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/7322#issuecomment-5705861744
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/pull/7322/c5705861744 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20260916/d42b4e75/attachment.htm>


More information about the rails-dev mailing list