Performance1 illustration

Cache and Push-Down Tuning Proposals

Read query run history back as concrete proposals: cache a query that never hits cache, or push a lingering filter down to the source.

These images are illustrations of the concept, not screenshots of the actual product.

Concept illustration of a performance tuning page with summary cards and stacked proposal cards for cache lifetime and push-down changes

Overview

Every federated run leaves evidence behind: how long it took, whether it was served from cache, how many sources it touched, and which filters had to be applied after the rows arrived instead of at the source. This concept collects that evidence across the workspace and turns it into a short list of specific, reviewable changes. The page sits under Performance in the left navigation, headed Tuning Proposals and described as suggestions from run history to review and apply.

Performance work usually stalls for a mundane reason: the signal is spread across hundreds of runs, so nobody can say which single setting is costing the most. The design answers that by gathering the proposals into one list and stating the evidence for each one inline. Three cards at the top count the queries analyzed, the proposals currently open and an estimated daily time saving if the open proposals were applied, all sample figures that frame the size of the opportunity.

Each proposal is a card built the same way: the query name, a badge naming the kind of change, a row of the measurements that justify it, and the proposed setting with its own actions. Two of the sample proposals concern caching. One is a query run dozens of times a day, taking several seconds on average, with a cache hit rate of zero and a very short lifetime configured; the proposal is to make it cacheable and extend the lifetime substantially. Another with a low hit rate and a thirty-second lifetime is proposed for a much longer one. The third proposal is a different kind of fix: a query touching three sources still carries residual predicates, and the proposal is to register one of those columns as a dimension so the filter can be pushed to the source instead of applied afterward. That card's action opens the model rather than changing a setting, because the real fix belongs in the semantic layer.

A side panel states the method plainly: the input is query run history, the signals are duration, cache hits, sources touched and residual predicates, and the output is proposals only. A second note reinforces that nothing is applied automatically, since a cache lifetime is a freshness decision that a person should own. Dismiss sits beside Apply on every card, so ignoring a proposal is a first-class outcome.

What this concept shows

Summary cards for queries analyzed, proposals currently open and estimated daily time saved
Proposal cards badged by change type, separating cache lifetime changes from push-down fixes
Inline evidence per proposal: runs per day, average duration, cache hit rate and current lifetime
A push-down proposal that names the residual predicates a query still applies after fetching rows
A proposed setting stated explicitly, such as making a query cacheable with a longer lifetime
Dismiss beside Apply on every card, with an Open Model action where the fix belongs in the semantic layer
A method panel naming the input, the signals used and the fact that the output is proposals only
A Refresh Analysis action for recomputing proposals from more recent run history

How it works

Open Performance in the left navigation to reach the tuning proposals.
Read the summary cards for how many queries were analyzed and how much time the open proposals could save.
Work down the proposal cards, which are badged by the kind of change they suggest.
Check the evidence on each card, such as runs per day, average duration, cache hit rate and current lifetime.
Apply a cache proposal where the freshness trade-off is acceptable, or dismiss it.
Open the model for a push-down proposal and register the column as a dimension so the filter reaches the source.
Refresh the analysis later to see how the applied changes moved the numbers.

Who it's for

Data platform engineers
Analytics engineers tuning slow queries
Analytics leads managing query cost
Data architects setting caching policy

Illustrations

1 illustration of this concept. Select one to view it full size.

A desktop layout with the product's left navigation, Performance selected, and a heading reading Tuning Proposals above a line describing them as suggestions from run history to review and apply. A Refresh Analysis button sits top right. Three cards report sample figures for queries analyzed, proposals open and estimated time saved per day. Below them, stacked proposal cards each pair a query name with a badge naming the change type. Two cache proposals show runs per day, average duration, cache hit rate and current lifetime, then state the proposed setting with Dismiss and Apply. A third, badged as a push-down change, shows runs per day, sources touched and the residual predicates still being applied, and proposes registering a column as a dimension, with an Open Model action. A side panel names the input, the signals used and states that nothing is applied automatically.