-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
🐌 Optimize incremental normalization runtime with snowflake #8088
Conversation
/test connector=bases/base-normalization
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ChristopheDuong thanks for listing the user impact! very helpful :) will these tables be removed automatically or is it something we'll need to remove over time? (or should they just never be removed? if they shouldn't be removed would it make sense to call them something other than _tmp
maybe _metadata
?)
it has to be kept with at least the row that has the maximum
|
|
Yes, it has to be 3, unless we increase the number of reserved characters here: Line 32 in ad3b7be
Let's go with |
/publish connector=bases/base-normalization
|
Closes #7775 |
What
Closes #7987 (comment)
Closes #8093
Closes #7775
How
_ab3
tables in Postgres since this breaks incremental (force a full refresh since the table would not exist anymore). So I renamed it_tmp
instead.Recommended reading order
🚨 User Impact 🚨
Not a breaking change but Postgres users will see "pollution" from an intermediate table on "dedupe history" mode that needs to be persisted (in a different staging schema) for incremental to work because of a limitation between dbt/Postgres. These tables will be suffixed with
_stg
On the other hand, the impact on the speed of this trade-off is difficult to measure without #7741