This page refers to the
persist_forparameter that is part of a
persist_forcan also be used as part of an explore, described here
persist_forcan also be used as part of a model, described here
persist_for: "24 hours"
AcceptsA string containing an integer followed by a timeframe (seconds, minutes, or hours)
Consider instead using a
datagroup_trigger, as described on this page about caching.
persist_for lets you set the maximum amount of time that a persistent derived table may be used before it is regenerated. When a user runs a query that relies on a
persist_for derived table, Looker checks the age of the table against
persist_for. If the age is greater than the
persist_for setting, the derived table is regenerated before the query is run. If the age is less than the
persist_for setting, the existing derived table is used.
If your admin has given you the
develop permission, you can force a derived table to regenerate before its
persist_for age has been reached. Select the Rebuild Derived Tables & Run option from the Explore Gear drop-down menu, which you’ll find in the upper right of the screen after running a query:
Regenerate the derived table if it is older than 1 hour
Regenerate the derived table if it is older than 1.5 hours
Regenerate the derived table if it is older than 1 day
persist_for Requires That You Have Enabled Persistent Derived Tables
persist_for will have no effect unless you have enabled persistence for derived tables on your Looker instance. Most customers do set up persistent derived tables when they initially configure Looker. The most common exception to this rule is for customers that connect Looker to a PostgreSQL read-only, hot-swap slave.
persist_for Works Differently Between Development Mode And Production Mode
persist_for should work as expected when in production mode. When in development mode all derived tables are persisted for a maximum of 24 hours, even if you set
persist_for to a longer value.
Things to Know
persist_for timeframe expires, Looker does not automatically regenerate a new derived table. Rather, the table is dropped, and a new derived table will be generated the next time a user queries it. Instead of waiting for a user query to trigger the generation of a derived table, you can schedule the automatic regeneration of a derived table using
Using datagroups with
datagroup_trigger, incorporates the functionality of both
sql_trigger_value. Datagroups can also be used to manage caching for queries that are not based on a PDT. See this page about caching for more information.