When building parameterized dashboards in Interactive Mode, you may notice that things start to feel sluggish as the number of parameters grows, or as the data behind an LOV (the list of values shown in a dropdown) gets larger.
We’re continuously working on server-side performance improvements, but there are also project design choices you can make today - without waiting for a product update - that can have a big impact. Here are two practices worth adopting.
1. Place parameter-filtering steps as far downstream as possible
If a step that filters by a parameter sits early in the pipeline (before a join or aggregation), then every time you change that parameter, everything downstream of it - including the heavy steps like joins and aggregations - has to be recomputed.
By moving the parameter-filtering step as far downstream as possible, you shrink the amount of work that needs to be redone each time a parameter changes.
- Before: Load → Filter by parameter → Join → Aggregate
(Every parameter change reruns the join and aggregation too) - After: Load → Join → Aggregate → Filter by parameter
(The join and aggregation now sit upstream of the parameter, so they are not rerun at all - their results are reused as-is. Only the filter step and what follows it reruns when a parameter changes)
The key is to get the heavy work upstream of the parameter. The heavier your joins and aggregations are, the bigger the payoff.
2. Build a small, deduplicated data frame dedicated to each LOV
The list of values (LOV) shown in a parameter dropdown is usually just “the distinct values in a column.” If that’s computed from the full raw table every time, the scan cost scales with the number of rows in that table.
Instead, prepare a small, dedicated data frame ahead of time that contains only the distinct values of the target column, and point the LOV at that instead. This changes the scan cost from scaling with “the number of rows” to scaling with “the number of distinct values” - a difference that grows significant as your data gets larger.
Here’s how to set it up:
- Create a branch from the data frame the choices come from.
- Use Select Columns to keep only the column you want the choices to come from.
- From the Filter menu, apply Remove Duplicated Rows (this shrinks the row count down to the number of distinct values).
- Open the parameter settings dialog, choose Data Frame as the way the choices are specified, and point it at the data frame and column you just created.
For example, if a 10-million-row table contains only 200 distinct store names, this one bit of setup takes the scan from 10 million rows down to 200 rows every time the dropdown is opened. The bigger your data, the more it pays off.
And if the choices barely ever change (think country names or department names), skip computing them from data altogether - typing them in as a static list is the fastest option of all.
Summary
| Practice | Where it helps most |
|---|---|
| Filter by parameter downstream | Dashboards where a parameter change triggers a heavy join/aggregation |
| Dedicated deduplicated LOV data frame | Dropdowns sourced from tables with many rows |
Both of these are purely about how you design the project. If an existing dashboard feels slow to respond to parameter changes, these two points are a good place to start.
We’re also continuing to work on performance improvements on the server side, so stay tuned for future updates. Questions or feedback? Let us know in the comments below.