partition_keys: [ "created_date" ]
- or -
AcceptsOne or more partitioned column names
partition_keys parameter supports database dialects that have the ability to partition columns. When a query is run that is filtered on a partitioned column, the database will scan only those partitions that include the filtered data, rather than scanning the entire table. Because a smaller subsection of the table is being scanned, this can significantly reduce the time and cost of querying large tables when the appropriate partition and filter are specified.
partition_keysparameter works only with tables that are persistent, such as PDTs and aggregate tables.
partition_keysis not supported for derived tables without a persistence strategy.
In addition, the
partition_keysparameter is not supported for derived tables that are defined using
When you create a persistent derived table (PDT) or an aggregate table, if your underlying database table uses partitioning, Looker can use that partitioning.
See the Dialect support for
partition_keyssection below for the list of dialects that support
To add a partitioned column to a PDT or an aggregate table, use
partition_keys and supply the names of the corresponding columns that are partitioned in the database table.
customer_day_facts PDT on a BigQuery database with a partition key on the
customer_day_facts SQL-based derived table on a Presto database with partition keys on the
Dialect support for
The ability to use
partition_keys depends on the database dialect your Looker connection is using. In Looker 21.8, the following dialects support
In BigQuery, partitioning can be used on only one table column, which must be a date/time column — so a Looker PDT based on a BigQuery table can use partitioning on only one date/time column.