The readPersistedAggregation() function can be used to retrieve pre-aggregated events that have been stored using a persisted aggregation. Persisted aggregations allow query results to be saved and reused across multiple queries, reducing the need to recompute expensive aggregations repeatedly. A persisted aggregation is referenced using a combination of tag and view. The function thus takes as input a tag and an optional view parameter and returns as output only the events associated with referenced persisted aggregation.

In this example, the readPersistedAggregation() function is used to retrieve all events stored under the tag myTag in the view myView. Only events matching the specified tag are returned; events from other tags in the same view are excluded.

In this scenario, a persisted aggregation has been set up to periodically aggregate web server access log data — counting requests per HTTP status code and endpoint — and store the results under the tag myTag in the view myView. The readPersistedAggregation() function is then used to read back those stored results for further analysis or visualization without re-running the original aggregation query.

Example incoming data might look like this:

The query is used to read back pre-aggregated web server access log data that was previously stored under the tag myTag in the view myView, returning all fields and events captured at the time the persisted aggregation was last written.

This query is useful, for example, to power dashboards or alerts that need to display aggregated HTTP traffic metrics — such as request counts, average response times, and error rates per endpoint and status code — without incurring the cost of re-running the full aggregation query over raw log data each time.

Sample output from the incoming example data:

Note that the output is a direct reflection of the data stored in the persisted aggregation at the time it was last written — no additional filtering, transformation, or re-aggregation is applied by the readPersistedAggregation() function itself.

Note also that events from other tags that may exist within myView are entirely absent from the results, confirming that the tag filter is applied strictly. Note that the error_rate field carries a value of 1.00 for all non-2xx and non-3xx status codes, reflecting that these were pre-computed and stored as part of the original aggregation logic, and their meaning depends entirely on how the persisted aggregation was defined.