References → Spark SQL View Caching

Overview

Starting v8.0.0 - 2026.8, Spark SQL view results are cached on the engine. Previously, every dashboard, insight, or filter and list-of-values request re-ran the view's query on the Advanced SQL Interface from scratch. With caching, a Spark SQL view's result is stored on the engine after its first execution, when applicable, and reused by subsequent requests, eliminating repeated executions of the same view.

Cache reuse

A cached result is reused only when a request matches the original execution exactly: the same view with the same filters, the same presentation variable values, and the same insight filters executed as part of the view's query. Requests that differ in any of these produce a separate cache entry, which guarantees that a reused result is always correct for the request being served.

To serve future requests from the same cached copy regardless of which columns they need, a view that is being cached retrieves all of its columns up front, rather than only the columns needed by the requesting insight. Views that are not cacheable continue to retrieve only the columns the current request requires.

Filter execution configuration

A tenant configuration, Execute Spark SQL view insight filters using Spark, available in the CMC under Cluster Configuration > Incorta Labs, controls where filters applied by insights and dashboards on a Spark SQL view's columns are executed:

• Enabled (default): Preserves the previous filter behavior where insight and dashboard filters on the view's columns are included in the view's query whenever applicable and run as part of the view's query on Spark, speeding up individual insights. Each distinct filter combination is cached as a separate entry, reducing the cache hit rate.
• Disabled: These filters are applied after the view runs, allowing insights with different filters to reuse the same cached result and increasing the cache hit rate.

Cache invalidation

Cached view results, along with the cached results of insights built on them, are automatically invalidated when any of the following are loaded or updated:

• The physical schemas referenced by the view's query
• The business schemas referenced by the view's query, including their source schemas
• The Spark SQL view itself

Non-cached views

A view is not cached if its query uses something that can produce a different result on every run:

• The current date or time
• A random value
• An auto-generated unique identifier
• One of the following SQL functions: curdate, current_date, current_timestamp, local_timestamp, localtimestamp, monotonically_increasing_id, randn, rand(), now(), statement_timestamp, transaction_timestamp, unix_timestamp, and uuid
• A session variable value

Such views always execute fresh for all request types: dashboards, insights, filter and prompt search, and list-of-values.

Limitations & known issues

• If a Spark SQL view executes for the first time while a metadata update to one of its source schemas is still propagating, the view may cache a result based on the outdated metadata.
  • Workaround: Make any edit to the Spark SQL view and save it, or update one of its referenced schemas, to refresh the cached entry.
• Avoid using any of the non-cacheable function keywords listed in the Non-cached views section (for example, now(), rand(), uuid, randn) even in your view comments. If present, the view will not be cached even though comments don't affect query results.