Grafana Time Comparison Memory: Why Extra Points?
This article explains why a Grafana time comparison query can return more data points than the original time range, and how to control that behavior. The short answer: Grafana’s time shift feature (e.g., time range compared to) does not change the underlying query resolution; it simply re-labels the same series with a shifted timestamp, so the number of points is identical to the base query. If you see extra points, they come from a different query, a different interval, or a data source that returns more samples than expected.
Background: How Grafana Handles Time Ranges
Grafana is a visualization layer. When you set a time range (say, last 24 hours), Grafana passes that range to the data source (Prometheus, InfluxDB, SQL, etc.) along with a recommended step or interval. The data source returns a series of data points, one per interval. Grafana then plots those points. The number of points is determined by the range divided by the interval, not by the number of raw samples stored.
For example, with a 24-hour range and a 1-minute interval, you expect roughly 1440 points. If the data source has more frequent samples, it may down-sample them to the interval. If it has fewer, it may fill gaps. The key is that the interval is the primary control.
How Time Comparison Works in Grafana
To compare the current period with a previous one, Grafana offers a time shift option. In the query editor, you can set a relative time shift (e.g., 1d or 7d). This tells Grafana to take the current time range, subtract the shift, and run the same query against that older window. The result is then displayed as a separate series, often with a legend like “now-1d�.
Critically, the time shift does not change the interval or the number of points. If the base query returns 100 points, the shifted query also returns 100 points. They are just aligned to the same x-axis (the current time range) for comparison. So where do extra points come from?
Common Sources of Extra Points
If you see more points than expected, check these possibilities:
- Multiple queries: You may have added a separate query for the comparison (e.g., a second query with a different time shift) instead of using the built-in time shift. Each query returns its own set of points, so the total count doubles.
- Different interval: Some data sources (like Prometheus) allow you to set a custom step per query. If one query uses a smaller step, it returns more points.
- Raw data without aggregation: If you query a table that stores one row per event (e.g., logs), and you don’t aggregate, you get one point per event, which can be far more than the interval count.
- Data source behavior: Certain data sources (like Graphite) may return multiple series for a single query (e.g., one per host), and each series is counted as a separate set of points.
- Time zone or offset: If the time shift is not an exact multiple of the interval, the shifted query may start at a slightly different offset, but that does not change the count—only the alignment.
How to Control the Number of Points
To avoid unexpected point counts, use the built-in time shift feature rather than duplicating queries. In the query editor, look for “Time shift� (or “Offset� in Prometheus) and set it to the desired comparison period. This ensures the same interval is used for both series.
If you need a different resolution for the comparison, you can set a custom step. For example, in Prometheus, you can add step=300 to the query to force a 5-minute interval. But remember that the shifted query will use the same step unless you override it.
For raw event data, always apply an aggregation function (e.g., count, avg, sum) with a time bucket to reduce the number of points to the expected interval.
Common Misconception: “Extra Points Mean More Data�
Some users think that if they see more points in the comparison, the data source has more samples for that period. That is rarely true. The number of points is a function of the query interval, not the underlying data density. If you query a metric that has a sample every second but set a 1-minute interval, you get one point per minute, regardless of how many raw samples exist. The same holds for the shifted query.
If you genuinely need more granularity, reduce the interval (e.g., from 1m to 30s). But be aware that this increases the load on the data source and may slow down the dashboard.
How to Diagnose Point Count Issues
When you see an unexpected number of points, inspect the query inspector. In Grafana, open the query inspector (the “Inspector� button) and look at the “Query� tab. It shows the exact request sent to the data source, including the time range, step, and any time shift. Check if the step is what you expect. Also look at the “Data� tab to see the actual number of data points returned per series.
If the count is still confusing, try running the same query in the data source’s native UI (e.g., Prometheus’s console) with the same step and time range. That will tell you if the data source itself returns that many points.
Performance and Cost Considerations
More data points mean more memory and CPU usage in Grafana, and more load on the data source. If you are comparing long ranges (e.g., 30 days) with a 1-second interval, you could end up with millions of points, which can crash the browser or slow the backend. Always choose an interval that matches the granularity you need. For long ranges, use a larger step (e.g., 1 hour) to keep the point count manageable.
Some data sources, like Prometheus, have a max_points limit in Grafana’s data source settings. If the calculated step would produce more than that, Grafana automatically increases the step to stay under the limit. This is a safety valve, but it can also cause the number of points to differ from your expectation.
Frequently Asked Questions
Why does my time comparison show twice as many points?
Most likely because you have two separate queries—one for the current period and one for the comparison—instead of using the built-in time shift. Each query returns its own series, so the total point count doubles. Use the time shift option to keep a single query.
Can I set a different interval for the comparison query?
Yes, if you use a separate query, you can set a custom step for each. But if you use the built-in time shift, the interval is the same. To have different intervals, you must write two queries.
Why does the comparison series have gaps?
Gaps usually mean the data source returned no data for those time buckets. This can happen if the shifted period had no samples (e.g., a service was down). It is not a Grafana issue.
How do I reduce the number of points in a time comparison?
Increase the step/interval. In Prometheus, you can set a larger step in the query options. In SQL data sources, use a larger time bucket in your aggregation. Also, consider using the max data points setting in the panel to let Grafana auto-adjust.
Does the time shift affect the interval?
No. The interval is calculated from the current time range and the panel’s “Min interval� or the data source’s step. The time shift only moves the start and end times of the query back by the specified amount.
Why does my comparison series start at a different time than the base series?
That happens if the time shift is not aligned to the interval. For example, if you shift by 1 hour but the interval is 15 minutes, the shifted query starts at the same minute as the base query minus 1 hour, which is fine. But if you shift by 1 day and the interval is 1 hour, the shifted query starts at the same hour of the previous day, so it aligns correctly. If you see a misalignment, check your time zone settings and the shift value.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.