feat: approximate-by-default measures with `exact_expression` and an inline exact chip by nishantmonu51 · Pull Request #10032 · rilldata/rill

nishantmonu51 · 2026-10-17T17:35:45Z

Measures can define an exact_expression next to their approximate expression, and dashboards let viewers switch a measure to its exact value on demand.

Runtime: exact_expression on measures (parsed, validated, in the reference docs); exact on MetricsViewAggregationMeasure and exact_measure_names on MetricsViewTimeSeriesRequest. The executor resolves the exact set once per query (closure over referenced measures) and passes it to every rewrite and AST; rollups are skipped for exact queries; rill.metrics.exact_measures is a kill switch. The AI query_metrics_view tool exposes the flag.
Explore: a ≈/= chip next to measures with an exact variant on big numbers, leaderboard and dimension table headers, the TDD header and table, and pivot column headers. A chip switches its own surface only (the big-number row, one leaderboard, the dimension table, the TDD table or the pivot). The selection is tab memory, never written to the URL, and resets when filters, time controls or the view change. One-shot exports follow what is on screen.
Canvas: the same chip per KPI and per table, pivot and leaderboard column, plus one chip next to a chart's title that switches every measure of the chart. The selection is per widget and resets when the canvas URL params change.
Docs: exact_expression in the measures reference, a guide page for the chip, and the canvas widget docs.
Tests: Go tests for parsing, AST, executor, rollups, validation and queries; vitest for the selection logic and the surfaces; a web-local e2e spec on a new AdBids_exact_metrics fixture.

Checklist:

Covered by tests
Ran it and it works as intended
Reviewed the diff before requesting a review
Checked for unhandled edge cases
Linked the issues it closes
Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
Intend to cherry-pick into the release branch
I'm proud of this work!

…inline exact chip Measures can define an `exact_expression` next to their approximate `expression`. Queries flag measures with `exact`; the runtime resolves the exact set once per query, skips rollups for it and honours the `rill.metrics.exact_measures` kill switch. Explore and canvas dashboards show a `≈`/`=` chip next to such measures and keep the selection in tab memory, per surface (one chip per chart in canvas).

…measures

AdityaHegde

High level review, just one comment about executor code.

AdityaHegde · 2026-10-20T13:13:10Z

 		return nil, err
 	}

+	exactMeasures, err := e.resolveExactMeasures(qry)


Instead of passing around exact measures everywhere how about running a rewrite at once place? Not sure if there is a good path for this.

Done: rewriteQueryExactMeasures resolves the set once at the start of Query and Export; nothing is passed around any more (details in the exact.go threads).

- match the Connect `MetricsViewAggregation` endpoint instead of the REST path - give the `publishers` measure a deterministic default expression - rename the fixture to `AdBids_precision_metrics` so that it sorts after `AdBids_metrics` and does not become the canvas editor's default metrics view

…measures # Conflicts: # proto/gen/rill/runtime/v1/resources.pb.go

…measures # Conflicts: # proto/gen/rill/runtime/v1/resources.pb.go # runtime/server/downloads.go

… passing the set around - `rewriteQueryExactMeasures` runs after validation in `Query` and `Export`: it resolves the exact set, writes it back into the query's `exact` flags (filter subqueries included) and applies the kill switch - `NewAST` resolves the set from the query it receives; derived queries (percent-of-total totals, two-phase base query, Druid TopN inner query, where-subqueries) copy the flags with the measures - removes `NewASTWithExactMeasures`, `resolveExactMeasures`, the private `query` and the extra parameter on the four rewrites - the set is closed under the derived-measure rule the frontend already uses: a measure calculated from an exact measure makes its other exact-capable inputs exact - tests for the fixpoint, `FlagExactMeasures` and a two-phase base query sharing a filter subquery

…e-resolving them per AST - `Query.ExactMeasures` (not part of the wire format) holds the set resolved once by `rewriteQueryExactMeasures` - derived queries (percent-of-total totals, two-phase base query, Druid TopN inner query, where-subqueries) copy it like their other context fields; the rollup check reads it - `NewAST` reads it and resolves from the flags only for queries that did not pass through the executor (schema probe, search) - removes `FlagExactMeasures`; the percent-of-total base measure is built as on main again

AdityaHegde

TDD's totals rows seem to be dependant on chart total's toggle rather than the toggle in TDD table.

AdityaHegde

Just a few nits remaining, approving

pjain1 · 2026-10-22T14:40:21Z

Do we need to allow exact behaviour for derived and ad hoc measures? Not supporting it will remove the parsing of sql which seems unnecessary for an optional feature or if we need to support exact on individual measures rather than at query level enabling for all measures.

pjain1 · 2026-10-22T14:57:21Z

 			typ = runtimev1.MetricsViewSpec_MEASURE_TYPE_TIME_COMPARISON
 		default:
 			return fmt.Errorf(`invalid measure type %q (allowed values: simple, derived, time_comparison)`, measure.Type)
 		}


disallow it on non simple measures? add a check here after switch like this

if measure.ExactExpression != "" && (typ != runtimev1.MetricsViewSpec_MEASURE_TYPE_SIMPLE || window != nil) { return fmt.Errorf(`measure %q: "exact_expression" can only be set on simple measures`, measure.Name) }

Done, with windowed measures excluded as well.

- `exact_expression` is only allowed on simple measures without a window (parser error otherwise) - the exact set is the flagged measures that define an exact_expression; no closure over referenced measures, no fixpoint, no parsing of ad hoc expressions. A derived measure is calculated from the measures as the query computes them - UI: derived and ad hoc measures show no chip; the dashed "inherited" chip state and its message are removed - the search paths run `rewriteQueryExactMeasures` - the Time Dimension Detail page is one surface: its chart, totals and table follow the chip in its header - the canvas chart builds its exact request set from its selection alone, without reading the metrics view spec or converting ad hoc measures - docs, schema description and the proto comment on `MetricsViewAggregationMeasure.exact` updated, bindings and reference docs regenerated

nishantmonu51 · 2026-10-22T21:33:48Z

@pjain1 agreed and done in a83302a: exact_expression is only allowed on simple measures (parser check, windows excluded too), the runtime no longer follows referenced measures or parses ad hoc expressions, and the UI drops the dashed state: derived and ad hoc measures show no chip and are calculated from the measures as the query computes them.

@AdityaHegde the TDD totals row is fixed in the same push: the Time Dimension Detail page is one surface now, so its chart, totals row and table all follow the chip in the TDD header.

…ected Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…inline exact chip (#10032) * feat: approximate-by-default measures with `exact_expression` and an inline exact chip Measures can define an `exact_expression` next to their approximate `expression`. Queries flag measures with `exact`; the runtime resolves the exact set once per query, skips rollups for it and honours the `rill.metrics.exact_measures` kill switch. Explore and canvas dashboards show a `≈`/`=` chip next to such measures and keep the selection in tab memory, per surface (one chip per chart in canvas). * test: fix the exact measures e2e spec and its fixture - match the Connect `MetricsViewAggregation` endpoint instead of the REST path - give the `publishers` measure a deterministic default expression - rename the fixture to `AdBids_precision_metrics` so that it sorts after `AdBids_metrics` and does not become the canvas editor's default metrics view * refactor: resolve exact measures once with a query rewrite instead of passing the set around - `rewriteQueryExactMeasures` runs after validation in `Query` and `Export`: it resolves the exact set, writes it back into the query's `exact` flags (filter subqueries included) and applies the kill switch - `NewAST` resolves the set from the query it receives; derived queries (percent-of-total totals, two-phase base query, Druid TopN inner query, where-subqueries) copy the flags with the measures - removes `NewASTWithExactMeasures`, `resolveExactMeasures`, the private `query` and the extra parameter on the four rewrites - the set is closed under the derived-measure rule the frontend already uses: a measure calculated from an exact measure makes its other exact-capable inputs exact - tests for the fixpoint, `FlagExactMeasures` and a two-phase base query sharing a filter subquery * refactor: store the resolved exact measures on the query instead of re-resolving them per AST - `Query.ExactMeasures` (not part of the wire format) holds the set resolved once by `rewriteQueryExactMeasures` - derived queries (percent-of-total totals, two-phase base query, Druid TopN inner query, where-subqueries) copy it like their other context fields; the rollup check reads it - `NewAST` reads it and resolves from the flags only for queries that did not pass through the executor (schema probe, search) - removes `FlagExactMeasures`; the percent-of-total base measure is built as on main again * refactor: drop exact behavior for derived and ad hoc measures - `exact_expression` is only allowed on simple measures without a window (parser error otherwise) - the exact set is the flagged measures that define an exact_expression; no closure over referenced measures, no fixpoint, no parsing of ad hoc expressions. A derived measure is calculated from the measures as the query computes them - UI: derived and ad hoc measures show no chip; the dashed "inherited" chip state and its message are removed - the search paths run `rewriteQueryExactMeasures` - the Time Dimension Detail page is one surface: its chart, totals and table follow the chip in its header - the canvas chart builds its exact request set from its selection alone, without reading the metrics view spec or converting ad hoc measures - docs, schema description and the proto comment on `MetricsViewAggregationMeasure.exact` updated, bindings and reference docs regenerated * deprecate exact field on query level * perf: skip serializing the query context when no exact measure is selected Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Parag Jain <pjain1@apache.org> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 9c1fdd2)

nishantmonu51 requested a review from pjain1 October 17, 2026 17:35

Merge remote-tracking branch 'origin/main' into nishant/approx-exact-…

b21dd4b

…measures

AdityaHegde self-requested a review October 20, 2026 05:41

AdityaHegde reviewed Oct 20, 2026

View reviewed changes

nishantmonu51 added 2 commits October 21, 2026 11:55

Merge remote-tracking branch 'origin/main' into nishant/approx-exact-…

181df08

…measures # Conflicts: # proto/gen/rill/runtime/v1/resources.pb.go

nishantmonu51 requested a review from AdityaHegde October 21, 2026 22:12

nishantmonu51 added 2 commits October 22, 2026 03:51

Merge remote-tracking branch 'origin/main' into nishant/approx-exact-…

b3c76ae

…measures # Conflicts: # proto/gen/rill/runtime/v1/resources.pb.go # runtime/server/downloads.go

AdityaHegde reviewed Oct 22, 2026

View reviewed changes

Comment thread runtime/metricsview/exact.go Resolved

Comment thread runtime/metricsview/exact.go Resolved

AdityaHegde reviewed Oct 22, 2026

View reviewed changes

Comment thread runtime/metricsview/executor/executor.go Resolved

Comment thread web-common/src/features/canvas/components/charts/CanvasChart.svelte Resolved

Comment thread web-common/src/features/canvas/components/charts/BaseChart.ts Resolved

AdityaHegde approved these changes Oct 22, 2026

View reviewed changes

pjain1 reviewed Oct 22, 2026

View reviewed changes

pjain1 and others added 2 commits October 23, 2026 12:30

deprecate exact field on query level

4a5dd2e

perf: skip serializing the query context when no exact measure is sel…

bd011e3

…ected Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

pjain1 approved these changes Oct 23, 2026

View reviewed changes

nishantmonu51 merged commit 9c1fdd2 into main Oct 23, 2026
17 checks passed

nishantmonu51 deleted the nishant/approx-exact-measures branch October 23, 2026 17:04

Navigation Menu

Repository navigation

feat: approximate-by-default measures with `exact_expression` and an inline exact chip - #10032

feat: approximate-by-default measures with `exact_expression` and an inline exact chip#10032
nishantmonu51 merged 10 commits into
mainfrom
nishant/approx-exact-measures

nishantmonu51 commented Oct 17, 2026

Uh oh!

AdityaHegde left a comment

Uh oh!

AdityaHegde Oct 20, 2026

Uh oh!

nishantmonu51 Oct 22, 2026

Uh oh!

Uh oh!

Uh oh!

AdityaHegde left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AdityaHegde left a comment

Uh oh!

pjain1 commented Oct 22, 2026

Uh oh!

pjain1 Oct 22, 2026 •

edited

Loading

Uh oh!

nishantmonu51 Oct 22, 2026

Uh oh!

nishantmonu51 commented Oct 22, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

nishantmonu51 commented Oct 17, 2026

Uh oh!

AdityaHegde left a comment

Choose a reason for hiding this comment

Uh oh!

AdityaHegde Oct 20, 2026

Choose a reason for hiding this comment

Uh oh!

nishantmonu51 Oct 22, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

AdityaHegde left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AdityaHegde left a comment

Choose a reason for hiding this comment

Uh oh!

pjain1 commented Oct 22, 2026

Uh oh!

pjain1 Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nishantmonu51 Oct 22, 2026

Choose a reason for hiding this comment

Uh oh!

nishantmonu51 commented Oct 22, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

pjain1 Oct 22, 2026 •

edited

Loading