From a800910dfa1a1a33bf3df6db35a107e7920c22a8 Mon Sep 17 00:00:00 2001 From: Graham McIntire Date: Fri, 20 Feb 2026 09:06:43 -0600 Subject: [PATCH] Remove completed items from TODO.md --- TODO.md | 21 --------------------- 1 file changed, 21 deletions(-) diff --git a/TODO.md b/TODO.md index 6d2760f..37f5396 100644 --- a/TODO.md +++ b/TODO.md @@ -1,19 +1,5 @@ # Performance TODO -## N+1 query in load_rf_path_station_packets - -`index.ex:895` — `handle_info({:load_rf_path_station_packets, stations})` still does N+1 -`Packets.get_latest_packet_for_callsign/1` calls per station. Unlike the RF path position -lookup (which only needs lat/lng), this needs full packet data for building markers with -popups. A batch version of `get_latest_packet_for_callsign` returning full packets via -`DISTINCT ON` would eliminate this. - -## Batch remove_marker events - -`PacketProcessor.batch_dispatch({false, true}, ...)` still pushes individual `remove_marker` -events during batch processing. These are rare (packet goes out of bounds) but could be -batched into a single `remove_markers` event with a list of IDs if profiling shows it matters. - ## PostgreSQL table partitioning The packets table uses CTE-based batch DELETE for cleanup (7-day retention). Time-range @@ -25,10 +11,3 @@ time-bounded queries. This is a significant migration effort. Changed `:aprsme` from `write_concurrency` to `read_concurrency`. The only write is `:message_number` increment. If message throughput increases significantly, consider using `:atomics` or `:counters` instead of ETS for the message counter. - -## JS callsign→markerID reverse index - -The `new_packets` handler still scans all `markerStates` when converting old markers to -historical dots. The server now sends `convert_to_historical` callsign keys which narrows -the search, but the scan is O(markerStates) in the worst case. A `Map>` -reverse index maintained by `addMarker`/`removeMarker` would make this O(1).