I am querying VictoriaMetrics every 30 seconds with the following PromQL query:

sum by (label_1) (increase(sample_metric[1d]))

This query calculates the increase in sample_metric over the last 1 day (1d), grouped by label_1. However, every time this query runs, VictoriaMetrics has to recompute the increase over the entire 1-day window.

Question: Is there a configuration or approach in VictoriaMetrics that allows this query to be evaluated in a sliding window manner, so that instead of recalculating the entire 1-day increase each time, it only computes the delta since the last query execution (i.e., the last 30 seconds)?

My goal is to improve efficiency by reducing redundant computations while still obtaining accurate results.

Additional Context: I am using VictoriaMetrics. The query runs every 30 seconds in my system.

I am looking for a solution that minimizes query processing overhead while maintaining correctness.

I have been running the following query every 30 seconds:

sum by (label_1) (increase(sample_metric[1d]))

I expected that VictoriaMetrics would efficiently compute the increase over the last 1-day window, but I realized that every execution recalculates the increase over the full 1-day period, which seems redundant.

I also checked VictoriaMetrics documentation to see if there is an incremental computation option or a way to implement a sliding window mechanism, but I couldn't find a clear solution.

What was I expecting?

I was hoping for a way where VictoriaMetrics would only compute the delta since the last query execution (i.e., the last 30 seconds instead of the full 1-day window each time). This would help improve efficiency and reduce the query load.

Is there a configuration or query optimization that allows for such a sliding window computation?

I am querying VictoriaMetrics every 30 seconds with the following PromQL query:

sum by (label_1) (increase(sample_metric[1d]))

This query calculates the increase in sample_metric over the last 1 day (1d), grouped by label_1. However, every time this query runs, VictoriaMetrics has to recompute the increase over the entire 1-day window.

Question: Is there a configuration or approach in VictoriaMetrics that allows this query to be evaluated in a sliding window manner, so that instead of recalculating the entire 1-day increase each time, it only computes the delta since the last query execution (i.e., the last 30 seconds)?

My goal is to improve efficiency by reducing redundant computations while still obtaining accurate results.

Additional Context: I am using VictoriaMetrics. The query runs every 30 seconds in my system.

I am looking for a solution that minimizes query processing overhead while maintaining correctness.

I have been running the following query every 30 seconds:

sum by (label_1) (increase(sample_metric[1d]))

I expected that VictoriaMetrics would efficiently compute the increase over the last 1-day window, but I realized that every execution recalculates the increase over the full 1-day period, which seems redundant.

I also checked VictoriaMetrics documentation to see if there is an incremental computation option or a way to implement a sliding window mechanism, but I couldn't find a clear solution.

What was I expecting?

I was hoping for a way where VictoriaMetrics would only compute the delta since the last query execution (i.e., the last 30 seconds instead of the full 1-day window each time). This would help improve efficiency and reduce the query load.

Is there a configuration or query optimization that allows for such a sliding window computation?

• victoriametrics

1 Answer 1

VictoriaMetrics automatically performs this optimization starting from v1.95.0. It is recommended upgrading to the latest available release and verifying whether the caching of instant query results work as expected by tracing the query in VMUI . Switch to JSON tab, switch on trace query toggle and the execute the query multiple times. It should show multiple traces per query execution. The first trace should show longer query execution, while subsequent traces should show smaller execution times, and they should contain "optimized query execution" steps, which merge the previously cached query results with the results of queries on adjusted smaller lookbehind windows.