You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@superset.apache.org by jl...@apache.org on 2026/08/10 17:28:43 UTC
(superset) branch master updated: docs(cache): document native filter option cache warm-up strategy (#42953)
This is an automated email from the ASF dual-hosted git repository.
sadpandajoe pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/superset.git
The following commit(s) were added to refs/heads/master by this push:
new 7dc2afd377b docs(cache): document native filter option cache warm-up strategy (#42953)
7dc2afd377b is described below
commit 7dc2afd377b46c7c181600b5982d99bac56796f8
Author: Evan Rusackas <ev...@preset.io>
AuthorDate: Mon Aug 10 10:28:36 2026 -0700
docs(cache): document native filter option cache warm-up strategy (#42953)
Co-authored-by: Claude <no...@anthropic.com>
---
docs/admin_docs/configuration/cache.mdx | 44 +++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/docs/admin_docs/configuration/cache.mdx b/docs/admin_docs/configuration/cache.mdx
index f7a02df9817..efb2587646e 100644
--- a/docs/admin_docs/configuration/cache.mdx
+++ b/docs/admin_docs/configuration/cache.mdx
@@ -134,6 +134,50 @@ CELERY_CONFIG = CustomCeleryConfig
This will cache the top 5 most popular dashboards every hour. For other
strategies, check the `superset/tasks/cache.py` file.
+### Warming Up Native Filter Options
+
+Native filter Value-type dropdown option queries (e.g. `SELECT DISTINCT column FROM table`) are
+cached the same way as chart data, via `DATA_CACHE_CONFIG`. However, the strategies above only warm
+up chart render queries, so the first user to open a dashboard's filter dropdown after a cache entry
+expires still triggers a fresh database query.
+
+The `native_filter_options` strategy pre-populates the cache for these dropdown queries. It reads
+each dashboard's `native_filter_configuration`, builds the same `filter_select` chart-data query the
+frontend would send, and executes it as the configured `SUPERSET_CACHE_WARMUP_USER`:
+
+```python
+class CustomCeleryConfig(CeleryConfig):
+ beat_schedule = {
+ **CeleryConfig.beat_schedule,
+ 'cache-warmup-native-filters': {
+ 'task': 'cache-warmup',
+ 'schedule': crontab(minute=0, hour=3), # daily at 03:00
+ 'kwargs': {
+ 'strategy_name': 'native_filter_options',
+ 'dashboard_ids': [1, 2, 3],
+ },
+ },
+ }
+```
+
+Requirements and limitations:
+
+- `SUPERSET_CACHE_WARMUP_USER` must be set to a user with access to the dashboards and datasets
+ referenced by the native filters.
+- `DATA_CACHE_CONFIG` must use a backend that actually persists entries (Redis recommended); the
+ default `NullCache` discards writes, so warming has nothing to warm. The effective timeout also
+ needs to be positive — `NATIVE_FILTER_OPTIONS_CACHE_TIMEOUT = -1` disables cache writes for these
+ queries entirely, even with a working backend.
+- Schedule the warm-up at least as often as the effective native filter cache timeout (whichever of
+ `NATIVE_FILTER_OPTIONS_CACHE_TIMEOUT`, the chart/dataset/database timeout, or `DATA_CACHE_CONFIG`'s
+ default applies). A looser schedule still leaves a window of cold, unwarmed queries between expiry
+ and the next run — the daily example above assumes a TTL of a day or more.
+- Cache entries are warmed under the warm-up user's own cache partition, the same entry that user
+ would create by opening the filter dropdown manually. Users with a different role set or row-level
+ security context may still see a cache miss on first load.
+- Cascading/dependent native filters and search-term variants of filter option queries are not
+ warmed by this strategy.
+
## Caching Thumbnails
This is an optional feature that can be turned on by activating its [feature flag](/admin-docs/configuration/configuring-superset#feature-flags) on config: