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
Slow lint of ~1600 line generated query #1784
Comments
We have a fix for this about to be merged in #1744 . It would be good to know if that branch resolves your issue too. |
I did a
Slashed! Sure, it's still a lot more than 12 seconds, but that's an impressive improvement. 👍🏻 |
Indeed - nice job by @WittierDinosaur !! Hopefully get this out soon! |
@jdub Can you run it again, but with the |
Ah, didn't know about … without awful model:
… with awful model:
|
The fix has been merged and will be included in the next release so closing this issue. |
Expected Behaviour
Without my horrifying generated join/union:
Observed Behaviour
With my horrifying generated join/union:
Interesting to note: Though most of the time is spent processing prior to printing the lint messages, sqlfluff also spends quite a while doing… something… between printing lint messages and "All Finished".
Steps to Reproduce
This is a necessary evil, which we need not discuss. I have attached the dbt-compiled SQL and output of
sqlfluff parse
of a model that wraps this model in a CTE (thus the extra bits): stg_history__history.zipNote that the dbt source definitions for these tables include BigQuery wildcards, e.g.
Version
Configuration
The text was updated successfully, but these errors were encountered: