Conversation
This was referenced Sep 9, 2026
EhabY
force-pushed
the
feat/session-family-usage-rollup
branch
from
September 9, 2026 14:33
83aa8d3 to
cd9543f
Compare
EhabY
removed this pull request from stack #29110
September 9, 2026 14:34
EhabY
changed the base branch from
feat/session-count-family-attribution
to
feat/session-count-generic-queries
September 9, 2026 14:34
EhabY
added this pull request to stack #29135
September 9, 2026 14:35
EhabY
force-pushed
the
feat/session-family-usage-rollup
branch
from
September 10, 2026 11:27
cd9543f to
bdac30a
Compare
EhabY
force-pushed
the
feat/session-family-usage-rollup
branch
from
September 10, 2026 11:54
bdac30a to
d34d4b6
Compare
EhabY
force-pushed
the
feat/session-family-usage-rollup
branch
from
September 10, 2026 12:07
d34d4b6 to
32b28f7
Compare
EhabY
marked this pull request as ready for review
September 10, 2026 12:12
Replace the fixed per-family minute columns on template_usage_stats with template_usage_stats_session_families and template_usage_stats_session_apps, one row per bucket and name, so a session reported under a new app name is stored and reported instead of being dropped. Family attribution comes from the single codersdk registry, which the rollup and the insights reads take as one jsonb parameter of app name to family, so registering an app or a family needs no SQL change, no column, and no probe. Migration 000591 backfills the existing family totals into the child table and drops the fixed columns. GetTemplateInsights keeps the per-user aggregate as its only large grouping and applies the 30 minute cross-template cap only to the buckets that need it, and the rollup scans workspace_agent_stats once. At 302k history rows the 30 day read goes from 2.4x the fixed-column baseline to about 1.1x on typical data, and the (start_time, user_id) child indexes keep cross-template heavy data within about 2x.
Record a digest of each bucket's session usage rows on template_usage_stats and drive the child table deletes and upserts from the main upsert's RETURNING set, so a rollup only touches child rows for buckets whose session usage changed. Steady-state rollups measured 10% to 17% faster.
Length-prefix names in the digest input so registry changes cannot alias different child row sets. Pin child replacement and unchanged-row write elision with a regression. Renumber the unmerged session usage migration to 000592 because main now uses 000591. Generated by Coder Agents for @EhabY.
Generated by Coder Agents for @EhabY.
Move the session usage migration and fixtures to 000595 after main's task removal migrations. Update migration tests to use the preceding schema and remove the stale fixture migration reference. Generated by Coder Agents for @EhabY.
EhabY
force-pushed
the
feat/session-family-usage-rollup
branch
from
September 14, 2026 18:10
a16831d to
d17e5b7
Compare
code-asher
reviewed
Sep 15, 2026
| -- caps a user's minutes per half hour across templates, can look up one user's | ||
| -- rows through that prefix. The upsert's conflict target names the same | ||
| -- columns in the parent's order, satisfied by the unique index. | ||
| CREATE TABLE template_usage_stats_session_families ( |
Member
There was a problem hiding this comment.
Do we need this table? My instinct is that in the database we should only need to record per app rather than family. The family grouping seems more like a display-time thing to me that we do in code. We need the individual counts anyway to provide the breakdown in the dashboard, right? So eventually this table and associated queries would go unused.
I think the reduction in query complexity would be worth it, unless summing families is prohibitively expensive or something.
|
|
||
| COMMENT ON COLUMN template_usage_stats_session_families.usage_mins IS 'Total minutes the user has been using the family. Minutes shared by two apps of the family count once.'; | ||
|
|
||
| CREATE TABLE template_usage_stats_session_apps ( |
Member
There was a problem hiding this comment.
I forget what we landed on in the RFC, but maybe this should be a jsonb column just to be consistent with the web app minutes? Might need to rename the existing column web_app_usage_mins or something though
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.
Store per-app and per-family session minutes in
template_usage_stats_session_appsandtemplate_usage_stats_session_families, replacing the fixed family-minute columns. New apps and centrally defined families no longer require rollup schema changes; existing API, Prometheus, and telemetry outputs remain unchanged.Family minutes deduplicate overlapping apps, and insights retain the cross-template minute caps. Family attribution comes from the shared app-to-family mapping. A digest with length-prefixed names skips child-row writes for unchanged buckets without confusing names containing delimiters.
Migration
000592: backfill existing family totals, including SFTP, without inventing historical per-app detail. Workspace web-app usage remains separate. The migration backfills retained history and alterstemplate_usage_stats; exclusive locks acquired by the ALTERs last until the migration transaction commits. Downgrading discards per-app detail and families the old schema cannot represent. Already-merged migration000590is unchanged.Follows merged #28337 and #29134; #28338 enables the producers. Covers the storage portion of #27413. Dynamic external projections (#27411 and the remaining #27413 work) and the connection-log migration (#27412) remain separate.
Design decisions and performance context
GetTemplateInsightslatency was approximately unchanged (328 → 327 ms), while the overlapping-template case increased from 355 → 623 ms.GetTemplateInsightsByTemplateincreased from 207 → 279 ms on typical data and 271 → 1,211 ms on the overlap fixture.Review guide and line breakdown
Counts for head
32b28f7b27, relative to the PR base. Additions/deletions are diff lines, not net growth. Categories are mutually exclusive.Suggested review order:
migrations/000592_template_usage_stats_session_usage.{up,down}.sql: schema, historical family backfill, and downgrade behavior.queries/insights.sql: app/family minute accounting, cross-template caps, and digest-gated child writes.Description updated by Coder Agents for @EhabY.