Serve the timeline's connection counts from a rollup once workspaces reach millions of events

オープン
  • 何か問題がありますか？
#249 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
32/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
postgresql, sql, typescript
領域
backend, databases, performance

調査の方向性

Start by reading the activity_event_daily_counts rollup and its statement-level triggers from #201, then the query behind timeline_connection_event_counts and the pgTAP cases in supabase/tests/database/21_timeline_connection_event_counts.test.sql. Decide between extending the rollup with connection_id/severity or adding a sibling rollup, and reconcile London filter days against UTC rollup days. Done means the unfiltered badge renders under 100 ms at 2.3M events with explain analyze on the PR and the pgTAP cases unchanged and passing.

索引モデルが issue の本文から書いたものです。

説明

area: timeline enhancement impact: low priority: P3 size: M

Summary

The timeline's connection badges (#245, PR #248) are counted by timeline_connection_event_counts, which aggregates the workspace's activity_events on every timeline render. With no filters, that reads every event the workspace keeps. Retention keeps 13 months (HISTORY_RETENTION_MONTHS in src/lib/jobs/retention.ts).

Measured with explain analyze on committed data in an isolated Postgres 17.11 container (the supabase/postgres:17.11.0.011 image, default settings):

Workspace size Filter Execution time
23,000 events (local demo) none 5.5 ms
2.3 million events (#191 scale, 13 months) none 134 to 148 ms
2.3 million events severity critical 88 ms
2.3 million events last 30 days 54 ms
2.3 million events one day 1 ms

The unfiltered case at #191 scale is over the 100 ms interactive read budget. #245 accepted this, because no workspace is near that size today. This issue holds the follow-up.

Scope

  • Extend the activity_event_daily_counts rollup (#201) with connection_id and severity, or add a sibling rollup, kept by the same statement-level triggers.
  • Serve the badges from the rollup when the filters allow it: no date filter, or whole days. The timeline's date filter uses London days and the rollup uses UTC days, so a filtered window that does not line up with UTC days still needs the live table, or a London-day rollup.
  • Keep the rule that a badge counts exactly what the timeline lists. Reuse the supabase/tests/database/21_timeline_connection_event_counts.test.sql cases against the new path.

Acceptance criteria

  • The unfiltered badges for a 2.3 million event workspace render under 100 ms (explain analyze quoted on the PR).
  • The counts are unchanged for every filter combination covered by the pgTAP test.

Model: anthropic/claude-opus-5-5 | Reasoning effort: unknown

主要言語
TypeScript
スター
1
フォーク
1
平均マージ
6時間 56分
マージ済み PR（30日）
136

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

eddiejaoude/StackDash のほかの issue

eddiejaoude/StackDash の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。