Optimizing ClickHouse and HogQL queries

Optimizes ClickHouse and HogQL queries (HogQL compiles to ClickHouse), not Postgres / Django ORM. For an app-DB query (Model.objects.filter(...)), stop and use pganalyze plus the Postgres section of query-performance-optimization.md; Step 0 has the full triage.

Work from the ClickHouse SQL, not the HogQL. Get the ClickHouse SQL the query produces, optimize that, then translate the change back into the HogQL query, query runner, printer, or a migration. Reasoning about HogQL alone hides what ClickHouse executes.

Assumes you can write HogQL. For new queries from scratch use /writing-clickhouse-queries; for migration mechanics, /clickhouse-migrations.

Optimizing every query a team owns

When the job is "optimize all of team X's queries," build the full inventory first or you'll miss some.

1. Resolve the team to its owned paths with /establishing-code-ownership. Owned paths span backend Python and frontend/src/..., often across several products; don't silently narrow to one product or to the backend.
2. Find queries across every path. Most are Python (*QueryRunner, execute_hogql_query, raw sync_execute), but plenty are built client-side and POSTed to /query. Grep frontend/ for:
   • api.queryHogQL(...), HogQLQueryString, the hogql`...` template
   • NodeKind.HogQLQuery / kind: 'HogQLQuery' with a query: string
   • nodes that compile to ClickHouse: DataTableNode, EventsQuery, TrendsQuery/InsightVizNode, PropertyFilterType.HogQL
   • literals with SELECT ... FROM events, or product markers ('survey sent', $survey_id)