signalsLatest/lastSeen via signal_latest projection#284
Merged
Conversation
Rewrites getLatestQuery to emit aggregate shapes that ClickHouse's projection matcher picks up against the signal_latest_by_subject_source_name projection added in model-garage. Non-location signals use argMax + max(timestamp); location signals use argMaxIf + maxIf with the same non-(0, 0) filter the projection carries. Mixed queries UNION ALL the two shapes so each branch matches cleanly. Drops DEFAULT_LOOKBACK / Service.lookbackFrom and the timestamp WHERE clause on both getLatestQuery and getLastSeenQuery. The timestamp filter prevents projection matching, and the projection itself makes the lookback unnecessary -- queries now read a handful of pre-aggregated rows per (subject, source, name) regardless of history depth. Verified on ClickHouse 25.3 with a 20M-row ReplacingMergeTree signal table: all four query shapes (non-location latest, location latest, mixed UNION ALL with source filter, lastSeen) match the projection via system.query_log.projections, and results are byte-identical to force-base (optimize_use_projections=0) runs. Must deploy only after DIMO-Network/model-garage#257 is materialized in the target environment; otherwise these queries fall back to full-history scans.
Fix up weird topK test
zer0stars
added a commit
that referenced
this pull request
Jun 11, 2026
* perf(ch): serve lastSeen query from signal_latest projection The lastSeen UNION ALL branch aggregated max(timestamp) with no GROUP BY, which the prod projection matcher does not serve -- every signalsLatest/signalsSnapshot selecting lastSeen scanned the subject's full signal history (p50 ~2900ms vs ~380ms for the name-filtered branches, worse for high-history vehicles). Wrap the aggregate so the inner query groups by name at the signal_latest_by_subject_source_name projection grain; the outer query re-aggregates to a single row. Result shape and semantics unchanged. Refs #284 * build: pin golangci-lint and its installer to v2.12.1 master install.sh currently downloads the .sbom.json asset in place of the tarball, so checksum verification fails for every version and CI breaks on install-tools. Fetch install.sh from the release tag and pin the version instead of tracking latest/master.
zer0stars
added a commit
that referenced
this pull request
Jun 11, 2026
…les (#298) * chore: bump model-garage for signal_latest + summary table migrations Pinned to the feat/signal-latest-table branch head (pre-v1.0.13 pseudo-version); re-pin to the v1.0.13 tag once released. * perf(ch): serve latest-state and summary queries from precomputed tables signalsLatest/signalsSnapshot/lastSeen/availableSignals now read the precomputed signal_latest table (model-garage 00010) instead of fanning out across every part of the raw signal table. Location fields read kind=1 rows, which pre-filter (0,0) fixes, so plain argMax replaces argMaxIf. Supersedes the projection-matching shapes from #284/#297. dataSummary per-name count/first-seen/last-seen now read the AggregatingMergeTree summary tables (model-garage 00011) instead of aggregating the raw tables. Counts are over raw inserts, matching the approximation of the previous non-FINAL count(*) reads. * style(ch): alias latest location column value_location for UNION consistency Scanning is positional so agg_location worked, but the non-location branch of the latest UNION ALL aliases its zero tuple value_location; matching aliases keep the result shape self-describing. * chore: pin model-garage to v1.0.13 release tag
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
getLatestQueryso the aggregate shapes match thesignal_latest_by_subject_source_nameprojection added in DIMO-Network/model-garage#257 — non-location signals useargMax+max(timestamp), location signals useargMaxIf+maxIfwith the same non-(0, 0)filter the projection carries, mixed queriesUNION ALLthe two branches.DEFAULT_LOOKBACK/Service.lookbackFromand the timestampWHEREclause on bothgetLatestQueryandgetLastSeenQuery. The timestamp filter prevents projection matching, and the projection makes the lookback unnecessary — queries now read a handful of pre-aggregated rows per(subject, source, name)regardless of history depth.Why
signalsLatest/lastSeenpreviously needed a 60-day lookback to keep scans bounded. Vehicles that hadn't reported in the last 60 days returned empty fromsignalsLatest. The projection stores one pre-aggregated row per(subject, source, name), so the lookback is no longer load-bearing and the full history is cheap to query.Verification
ClickHouse 25.3 (podman), 20M-row
ReplacingMergeTreesignaltable, 200 subjects, 8 partitions, with the new projection materialized:system.query_log.projectionsmatchspeed,isIgnitionOn)argMaxIf+maxIfnon-(0,0))lastSeen(max(timestamp))Results byte-identical between projection and force-base runs (
SETTINGS optimize_use_projections = 0).Deploy order
Must deploy only after DIMO-Network/model-garage#257 is materialized in the target environment. Without the projection, the now-unbounded queries will do full-history scans — regression vs today's 60-day lookback. Hold the deploy until
system.mutationsshows theMATERIALIZE PROJECTIONmutation is done onsignalandevent.Removed config
DEFAULT_LOOKBACKenv var (was 60 in bothvalues.yamlandvalues-prod.yaml)DefaultLookbackDaysfield inconfig.SettingsService.defaultLookbackfield,Service.lookbackFrom(),defaultLookbackDaysconstsettings.sample.yamlTest plan
go test ./...passes (unit + e2e testcontainers)system.query_log.projectionson live traffic shows the projection being hitsignalsLatestp99signalsLatest