You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@joshuataylor You're right, the fix in #3149 will slow down column-level persist_docs for tables with many many columns. My sense at the time is that it's worth trading the reduction in speed for the reduction in errors.
Based on what you're seeing anecdotally, how much slower is drastically slower? We could think about reworking this again for v0.21, by checking column metadata, verifying that the user-specified columns exist, and then running a single alter statement.
This is awesome, thanks so much, will try it out. It was taking about 2 extra minutes per large table (~100ms I think to run on sf, so take the round trip time maybe an extra 2s end to end?), which is painful when you are charged for the larger warehouse sizes with SF. :-)
Describe the bug
With 0.19, having comments creates a query like this after the table is built:
Now it does a query per comment, which drastically reduces the speed of building large tables:
This is because of #3149 , I believe this a good fix but can lead to long build times for CI environments.
Steps To Reproduce
Expected behavior
A single alter table.
System information
Which database are you using dbt with?
The output of
dbt --version
:The output of
python --version
:Python 3.8.6
The text was updated successfully, but these errors were encountered: