Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Perf: Only recreate materialzed views when necessary #546

Closed
bmtcril opened this issue Dec 18, 2023 · 3 comments · Fixed by #628
Closed

Perf: Only recreate materialzed views when necessary #546

bmtcril opened this issue Dec 18, 2023 · 3 comments · Fixed by #628
Assignees
Labels
aspects v1 Issues blocking Aspects v1 release bug Report of or fix for something that isn't working as intended

Comments

@bmtcril
Copy link
Contributor

bmtcril commented Dec 18, 2023

With the move of MVs to dbt, we currently rebuild every mv table on every dbt run / aspects init. This will be a problem with large datasets over time, we want to only rebuild those tables when absolutely necessary. dbt has the on_configuration_change configuration option to support this, we'll need to upstream it to dbt-clickhouse then update.

See: https://docs.getdbt.com/docs/build/materializations#materialized-view

@bmtcril bmtcril added the aspects v1 Issues blocking Aspects v1 release label Dec 18, 2023
@Ian2012
Copy link
Contributor

Ian2012 commented Dec 18, 2023

@bmtcril are new MVs backfilled on creation?

@bmtcril
Copy link
Contributor Author

bmtcril commented Dec 18, 2023

@Ian2012 yes, and on every init / dbt run currently

@bmtcril bmtcril changed the title Only recreate materialzed views when necessary Perf: Only recreate materialzed views when necessary Jan 12, 2024
@bmtcril bmtcril added the bug Report of or fix for something that isn't working as intended label Jan 16, 2024
@SoryRawyer
Copy link
Contributor

After looking into this, the on_configuration_change setting is unlikely to prevent us from rebuilding the MVs on every run. As I understand it, there are two main approaches for us to avoid rebuilding MVs when we don't need to:

  • The state:modified selector, which would require us to track the state of each dbt run over time, since that selector requires the previous runs' manifest to compare to.
  • Adding a tag to each MV and selecting all models that don't have this tag. One approach could be to only select models materialized as views via the config selector

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
aspects v1 Issues blocking Aspects v1 release bug Report of or fix for something that isn't working as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants