Open ANich opened 2 years ago
For Explores that point to large tables like search_clients_daily, it's usually helpful to have aggregate tables smaller than the daily grain (weekly, monthly, etc.)
search_clients_daily
The always_filter on submission_date (https://github.com/mozilla/lookml-generator/blob/main/generator/explores/explore.py#L239-L240) for example means we can't aggregate to submission_month or submission_year so the fastest aggregate-aware queries we have will point to daily aggregates. We can get a lot faster for month/month year/year queries if we change that.
always_filter
submission_date
submission_month
submission_year
Opening this issue to gather thoughts on how to fix that.
One option is to remove the auto-generated always_filter for submission_date: 28 days in Explores eg. https://github.com/mozilla/looker-hub/blob/main/search/explores/desktop_search_counts.explore.lkml#L13-L17 and find another way to prevent huge scans. Any other ideas?
submission_date: 28 days
cc @Marlene-M-Hirose @scholtzan
Here's an example:
Ideally we'd have "Submission Month" in the past 3 months which would hit a monthly aggregated table.
For Explores that point to large tables like
search_clients_daily
, it's usually helpful to have aggregate tables smaller than the daily grain (weekly, monthly, etc.)The
always_filter
onsubmission_date
(https://github.com/mozilla/lookml-generator/blob/main/generator/explores/explore.py#L239-L240) for example means we can't aggregate tosubmission_month
orsubmission_year
so the fastest aggregate-aware queries we have will point to daily aggregates. We can get a lot faster for month/month year/year queries if we change that.Opening this issue to gather thoughts on how to fix that.
One option is to remove the auto-generated
always_filter
forsubmission_date: 28 days
in Explores eg. https://github.com/mozilla/looker-hub/blob/main/search/explores/desktop_search_counts.explore.lkml#L13-L17 and find another way to prevent huge scans. Any other ideas?cc @Marlene-M-Hirose @scholtzan