Skip to content

Conversation

@tcp13equals2
Copy link
Contributor

@tcp13equals2 tcp13equals2 commented Jan 2, 2026

What this PR does

This PR introduces metrics for tracking the effectiveness of the step invariant operator.

When an expression is marked as a step invariant, the float or histogram points are assumed to be the same at each step. As such, the inner data only needs to be queried once and the value re-used in each subsequent step.

This PR provides a metric to track the number of points saved / re-used.

This PR also adds a metric for tracking the total number of step invariant nodes which have been observed. Note that not ever step invariant node will result in savings. This can occur if the inner operator returns no data.

An enhancement has also been made to remove the step invariant operator if the query is an instant query - as this operator does not provide any useful value when there is only a single step of data.

The new metrics are;

  • cortex_mimir_query_engine_step_invariant_nodes_total
  • cortex_mimir_query_engine_step_invariant_points_saved_total - and this will have a type label of fpoint or hpoint

To assist in supporting a metric tracker being passed into the operator, a new MetricsTracker has been added to the query planner which is passed down to operators within the OperatorParameters. This could be re-used to allow other metric trackers to be passed into operators.

Which issue(s) this PR fixes or relates to

Fixes #

Checklist

  • [ x] Tests updated.
  • Documentation added.
  • [ x] CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]. If changelog entry is not needed, please add the changelog-not-needed label to the PR.
  • about-versioning.md updated with experimental features.

Note

Introduces metrics to observe step-invariant expression usage and savings, and avoids unnecessary wrapping for instant queries.

  • New operators/metrics tracker with counters: cortex_mimir_query_engine_step_invariant_nodes_total and cortex_mimir_query_engine_step_invariant_points_saved_total (labeled by type: fpoint/hpoint)
  • Planner now owns OperatorMetricsTracker and passes it via planning.OperatorParameters; engine wires it into operator params
  • StepInvariantInstantVectorOperator and StepInvariantScalarOperator updated to record node observations and saved points; constructors accept tracker
  • Materialization skips step-invariant operator when StepCount <= 1 (instant queries)
  • Tests added for tracker and end-to-end verification of node/point metrics; CHANGELOG updated

Written by Cursor Bugbot for commit 91ae18a. This will update automatically on new commits. Configure here.

@tcp13equals2 tcp13equals2 marked this pull request as ready for review January 2, 2026 06:23
@tcp13equals2 tcp13equals2 requested a review from a team as a code owner January 2, 2026 06:23
Copy link
Contributor

@tacole02 tacole02 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changelog LGTM

@charleskorn charleskorn changed the title Adding step invariant metrics and past path for instant queries. Adding step invariant metrics and fast path for instant queries. Jan 5, 2026
Comment on lines +101 to +105
// There is no advantage to wrapping an instant query in a step invariant
if timeRange.StepCount <= 1 {
return planning.NewSingleUseOperatorFactory(op), nil
}

Copy link
Contributor

@charleskorn charleskorn Jan 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we do this at planning time instead? (ie. not inject the step-invariant node if the time range has a single step)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should track only the number of times a step-invariant node is added as well as the number of steps (not samples) saved.

This would simplify things greatly as we could calculate these at planning time, rather than during evaluation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants