Notebooks
Reuse recent SQL results instead of querying your datasource again.
When a SQL cell queries a configured datasource, such as Snowflake, BigQuery, or PostgreSQL, Chalk can reuse the result of the cell’s last run instead of sending the query to the datasource again. This applies when the cell’s SQL and datasource have not changed since that run, and the run finished successfully within the cache’s max staleness.
A SQL cell that used a cached result shows Cached · before the time of its last run, in the top right of the cell header.
A run that uses a cached result gets its own copy of the result. Paging, downloads, and column aggregations on it work the same as on a result from the datasource.
To send a query to the datasource even when a cached result is available:
The new result replaces the cached result, so the next run of the cell can reuse it.
From the CLI, pass --no-cache to chalk notebook run to run without cached
results.
Max staleness is the oldest a cached result can be and still be reused. A value of 0 turns
caching off. Chalk uses the first of these settings that is set:
team.admin permission. Disabled (always run fresh) turns
caching off for every notebook in the environment, and a notebook setting cannot turn it
back on.From the CLI, chalk notebook run --max-staleness sets a lower max staleness for one run, such as
--max-staleness 5m. It cannot make the run reuse an older result than the settings allow.
A SQL cell can use a cached result only when all of the following are true:
SELECT or WITH.now(),
current_timestamp, or random().Changing the cell’s SQL or its datasource means the next run sends the query to the datasource. Renaming the cell or its result variable does not.
Chalk keeps notebook run history, including cached results, for 30 days. A result older than 30 days is never reused, whatever the max staleness setting.