Querying the Periscope Cache

👤 This documentation is intended for SQL Users on sites that have access to the Cache Infrastructure. Site Administrators can reach out to their Customer Success Manager if interested in enabling the Cache infrastructure on their instance.

Queries automatically run on the Periscope Cache if the underlying tables are cached and the SQL is Redshift-compatible. If the query fails on the Cache, Periscope Data will run it directly against the source database.

The database that the query is running against can be determined by hovering over the info icon in the chart editor. A green dot indicates that the query was run on the cache, while a grey dot indicates that the query ran directly on the source database.

Note: This functionality is only available with the cache add-on.

Forcing a Query to Run on the Cache

Users on Explicit Cache

Ensure that the "Cache" option is selected in the database selector on the left hand side of the chart editor, as shown in the documentation here.

Users not using Explicit Cache

To ensure that the query doesn't fall back to the source database, add --yes_cache or -- --yes_cache (for MySQL) to the top of the query.

For example, if a chart using a view called panthers_stats is showing an error about a nonexistent column, it may be falling back to the source database and giving an unhelpful error message.

Adding --yes_cache to the top of the query ensures that it doesn't fall back to the source database, where panthers_stats doesn't exist.

Now the chart shows a more relevant error.

Forcing a Query to Run on the Source Database

Users on Explicit Cache

Ensure that the desired database is selected in the database selector on the left hand side of the chart editor, as shown in the documentation here.

Users not using Explicit Cache

To run queries against the source database directly, there is a similar syntax. Add --no_cache or -- --no_cache (for MySQL) to the top of a query to skip the Periscope Cache.

Our support team is ready to help