https://linen.dev logo
Join Slack
Powered by
<@U088WCP3B4P> if I have the default vars in my db...
# ask-elementary-ai
a
@kapa.ai if I have the default vars in my dbt_project.yml set to
Copy code
vars:
  insert_rows_method: chunk
  dbt_artifacts_chunk_size: 10
  query_max_size: 100000
  disable_dbt_artifacts_autoupload: true
  disable_run_results: true
  disable_tests_results: true
  disable_dbt_invocation_autoupload: true
but I want to enable just one of the artifacts uploads like: dbt_tests dbt_run_results can I just override it with a --vars '{"disable_dbt_tests_autoupload": false, "disable_dbt_run_results_autoupload": false}' in the command line? Will that make sure that just the two artifacts that I'm interested in will run?
k
A message from kapa.ai
Based on the available knowledge sources, the documented way to control which dbt artifacts Elementary uploads is by setting specific variables in your 
dbt_project.yml
or via the command line using 
--vars
. The main variables documented are: - 
disable_dbt_artifacts_autoupload
- 
disable_run_results
- 
disable_tests_results
- 
disable_dbt_invocation_autoupload
These control the uploading of metadata and results models, as described in the documentation and community discussions. However, there is no mention in the official documentation or Slack threads of variables named 
disable_dbt_tests_autoupload
or 
disable_dbt_run_results_autoupload
. The correct variables to use for controlling test and run results uploads are 
disable_tests_results
and 
disable_run_results
, respectively. To enable just the upload of test results and run results (while keeping other uploads disabled), you should override the corresponding variables like this:
Copy code
bash dbt run --vars '{"disable_run_results": false, "disable_tests_results": false, "disable_dbt_artifacts_autoupload": true, "disable_dbt_invocation_autoupload": true}'
This will ensure that only the test results and run results are uploaded, while other artifact uploads remain disabled. Make sure you use the correct variable names as documented. There is no evidence in the knowledge sources that 
disable_dbt_tests_autoupload
or 
disable_dbt_run_results_autoupload
are valid or recognized by Elementary. Use the variables shown above for the desired behavior [FAQ - Can I disable the on-run-end hooks?](https://docs.elementary-data.com/dbt/on-run-end_hooks#can-i-disable-the-on-run-end-hooks%3F) [FAQ - Can I disable the on-run-end hooks or results uploading?](https://docs.elementary-data.com/oss/general/faq). If you need to override defaults set in your 
dbt_project.yml
, passing the variables via 
--vars
on the command line will take precedence, as confirmed in the documentation and Slack discussions. Summary: - Use 
disable_run_results
and 
disable_tests_results
to control run and test results uploads. - Set them to 
false
via 
--vars
to enable just those uploads. - The variable names you suggested (
disable_dbt_tests_autoupload
, 
disable_dbt_run_results_autoupload
) are not documented and likely will not work. If you need more granular control or if you are using a newer version of Elementary with undocumented features, please consult the latest official documentation or reach out to Elementary support.
a
if I only want the elementary_test_results to run
if I only want the elementary_test_results to run @kapa.ai would I only enabled the disable_test_results
k
A message from kapa.ai
If you only want the 
elementary_test_results
table to be populated (i.e., only upload test results), you should set the following in your 
dbt_project.yml
or via the command line:
Copy code
yaml vars:   disable_tests_results: false   disable_run_results: true   disable_dbt_artifacts_autoupload: true   disable_dbt_invocation_autoupload: true
This configuration will ensure that only the test results are uploaded to 
elementary_test_results
, and all other artifact uploads are disabled. The key variable to control this is `disable_tests_results`—set it to 
false
to enable test results uploads, and set the others to 
true
to disable their respective uploads. This approach is confirmed in the documentation and community discussions [Can I disable the on-run-end hooks?](https://docs.elementary-data.com/dbt/on-run-end_hooks#can-i-disable-the-on-run-end-hooks%3F) and [FAQ - Can I disable the on-run-end hooks or results uploading?](https://docs.elementary-data.com/oss/general/faq). If you want to do this via the command line, you can use:
Copy code
bash dbt run --vars '{"disable_tests_results": false, "disable_run_results": true, "disable_dbt_artifacts_autoupload": true, "disable_dbt_invocation_autoupload": true}'
This will ensure that only 
elementary_test_results
is updated.
a
@kapa.ai if all of those configurations are already set in my dbt_project.yml file that should be fine right? and I'll just override the disable_tests_results in the vars
k
A message from kapa.ai
Yes, that is correct. If you have all those configurations already set in your 
dbt_project.yml
file, you can override just the 
disable_tests_results
variable via the command line using 
--vars
. This will take precedence over the value set in your 
dbt_project.yml
and enable only the upload of test results to 
elementary_test_results
, while keeping the other uploads disabled. This approach is supported by the documentation, which states that you can use the vars in your command line to override the configuration in your 
dbt_project.yml
file [Can I disable the on-run-end hooks?](https://docs.elementary-data.com/dbt/on-run-end_hooks#can-i-disable-the-on-run-end-hooks%3F). For example:
Copy code
bash dbt run --vars '{"disable_tests_results": false}'
This will override the value from your 
dbt_project.yml
for that run.
a
how can I do a full refresh because one time it worked and the none time it didn't with the chunking @kapa.ai
k
A message from kapa.ai
To perform a full refresh of Elementary’s incremental models (including artifact tables), you need to use both the 
--full-refresh
flag and set the 
elementary_full_refresh
variable to 
true
. This is necessary because the standard 
--full-refresh
flag alone does not fully refresh Elementary’s incremental models due to how they are implemented. The correct command is:
Copy code
bash dbt run --select elementary --full-refresh --vars '{"elementary_full_refresh": true}'
This approach is confirmed in multiple support threads and is the recommended way to ensure all Elementary tables are fully refreshed, regardless of chunking or other insert methods you may have configured. If you only use 
--full-refresh
without the variable, it may not work as expected for Elementary models [Slack thread](https://slack.com/archives/C02CTC89LAX/p1682944161312479) [Slack thread](https://slack.com/archives/C02CTC89LAX/p1678374297642069). If you continue to have issues with chunking, ensure your variables for chunking (like 
insert_rows_method
and 
dbt_artifacts_chunk_size
) are set appropriately, but for a full refresh, the command above is the key step.
a
this is the configuration I have: insert_rows_method: chunk dbt_artifacts_chunk_size: 10 and then "disable_tests_results": false, "elementary_enabled": true, in my vars input into the cli
@kapa.ai this is the configuration I have: insert_rows_method: chunk dbt_artifacts_chunk_size: 10 and then "disable_tests_results": false, "elementary_enabled": true, in my vars input into the cli
k
A message from kapa.ai
Based on your configuration: - 
insert_rows_method: chunk
- 
dbt_artifacts_chunk_size: 10
- CLI vars: 
"disable_tests_results": false, "elementary_enabled": true
Here’s what is supported by the knowledge sources: 1. Chunking Configuration: Setting 
insert_rows_method: chunk
and 
dbt_artifacts_chunk_size: 10
is a valid way to control how many rows are inserted per query, which can help with large projects or BigQuery/Snowflake limits. This approach is referenced in several support threads and GitHub issues as a way to avoid query size or resource errors [GitHub Issue #1689](https://github.com/elementary-data/elementary/issues/1689). 2. Enabling Test Results Upload: Setting 
"disable_tests_results": false
in your CLI vars will enable the upload of test results to the 
elementary_test_results
table, even if it is disabled in your 
dbt_project.yml
. This is the correct way to override the default and ensure only test results are uploaded [FAQ - Can I disable the on-run-end hooks?](https://docs.elementary-data.com/dbt/on-run-end_hooks#can-i-disable-the-on-run-end-hooks%3F). 3. 
elementary_enabled
Variable: The knowledge sources do not mention a variable named 
elementary_enabled
. There is no documentation or support thread referencing this variable, so its effect is unknown. You can safely omit it unless you have specific documentation from a newer version or custom implementation. Summary: - Your chunking and test results configuration is correct and supported. - The 
elementary_enabled
variable is not documented in the available sources, so its effect is uncertain. - If you want only test results to be uploaded, your configuration should work as intended. If you encounter issues, double-check that your variables are set in the correct place (
dbt_project.yml
vs. CLI 
--vars
), as this has been a common source of confusion in the community [GitHub Issue #1689](https://github.com/elementary-data/elementary/issues/1689).
a
will this: insert_rows_method: chunk affect other dbt tests that are not elementary @kapa.ai
k
A message from kapa.ai
No, setting 
insert_rows_method: chunk
in your 
dbt_project.yml
or via 
--vars
will not affect other dbt tests that are not related to Elementary. This variable is specific to how Elementary uploads its artifacts and test results to your data warehouse. It only impacts the insert queries generated by Elementary’s on-run-end hooks and artifact uploads, not the execution or behavior of standard dbt tests or models. This is confirmed in community discussions, where it is clarified that these variables are internal to Elementary and only affect how Elementary handles its own metadata and results uploads—not the core dbt test execution or other dbt features [Slack thread](https://slack.com/archives/C02CTC89LAX/p1677869503258149). So, you can safely use 
insert_rows_method: chunk
for Elementary without worrying about unintended side effects on your other dbt tests.
a
@kapa.ai I've been running this command: dbt test --select tables --defer --state ./prod_artefacts/ --vars '{ "disable_tests_results": false, "elementary_enabled": true, "insert_rows_method": "chunk", "dbt_artifacts_chunk_size": 1 }' and I'm still seeing the database error when trying to insert into data_monitoring_metrics__tmp_20250515115619038995
k
A message from kapa.ai
Based on the knowledge sources, the error you’re seeing when trying to insert into 
data_monitoring_metrics__tmp_...
is a known issue that can occur in several scenarios, especially when using 
--defer
and state-based workflows. Here are the most relevant points from the sources: 1. Chunking and Query Size: Setting 
insert_rows_method: chunk
and a small 
dbt_artifacts_chunk_size
(like 1) is intended to help with query size or concurrency issues, especially on BigQuery or Snowflake. However, users have reported that even with these settings, errors can persist if there are permission issues or if the target table does not exist in the current environment. The chunking method only affects how Elementary inserts rows, not the creation of the temp tables themselves [GitHub Issue #1689](https://github.com/elementary-data/elementary/issues/1689), [Slack thread](https://slack.com/archives/C02CTC89LAX/p1677869503258149). 2. Defer and State Issues: When using 
--defer
, dbt will resolve references to models (including Elementary models) in the state directory if they do not exist in your current environment. If the Elementary tables (like 
data_monitoring_metrics
) do not exist in your dev/sandbox schema, dbt/Elementary may attempt to write to the production version, which can cause permission errors or missing table errors. This is a known limitation and has been discussed as a bug/limitation in Elementary when used with dbt's defer/state features [Slack thread](https://slack.com/archives/C02CTC89LAX/p1692696677104579), [Slack thread](https://slack.com/archives/C02CTC89LAX/p1717488789811829). 3. Workarounds: - Ensure Elementary Tables Exist in Your Target Environment: Before running your tests, run 
dbt run --select elementary
in your dev/sandbox environment to create the necessary Elementary tables. This ensures that inserts target your local environment, not production. - Permissions: Make sure your user has the necessary permissions to create and write to the temp tables in the target schema. - Disabling Hooks: If you do not need Elementary artifact uploads in non-prod environments, you can disable them using the documented variables, but this will also disable the test results uploads. Summary: Your chunking configuration is correct, but the error is likely due to the Elementary tables not existing in your current environment or a permissions issue. Run:
Copy code
bash dbt run --select elementary
in your dev/sandbox environment before running your tests to ensure the tables exist locally. This should resolve the issue with temp table creation and insertion [Slack thread](https://slack.com/archives/C02CTC89LAX/p1692696677104579), [Slack thread](https://slack.com/archives/C02CTC89LAX/p1717488789811829). If the problem persists after ensuring the tables exist and permissions are correct, it may be a deeper issue with how Elementary interacts with dbt's defer/state features, which is a known limitation.
a
@kapa.ai my tables exist
k
A message from kapa.ai
Thank you for clarifying that your tables exist. Given that, and based on the knowledge sources, if you are still seeing a database error when trying to insert into a temp table like 
data_monitoring_metrics__tmp_...
, even with chunking enabled, there are a few additional considerations: 1. Temporary View Persistence in Databricks/Spark: There are known issues where temporary views or tables created by Elementary are not found at the time of insertion, especially on Databricks and Spark. This can happen even if the base tables exist, due to how temp views are managed and their lifecycle within a session or cluster. The error you’re seeing matches previously reported issues where the temp view is deleted or unavailable by the time the insert statement runs. This is not always resolved by chunking or by the existence of the base tables alone. Upgrading to the latest Elementary package has resolved this for some users, but not all edge cases are covered, especially in Databricks/Spark environments [Slack thread](https://slack.com/archives/C02CTC89LAX/p1692603763973949). 2. Concurrency and Cluster Reuse: If you are running on a shared or long-lived Databricks cluster, temp views from previous runs may persist or conflict, or the cluster may "forget" temp views between steps. This has been reported as a source of intermittent issues, and some users have worked around it by using fresh clusters for each run or by ensuring no concurrent runs use the same schema and temp view names [Slack thread](https://slack.com/archives/C02CTC89LAX/p1675261328664329). 3. Elementary Version: Some issues with temp table handling have been fixed in newer versions of the Elementary dbt package. If you are not on the latest version, upgrading may help, as there have been targeted fixes for Spark/Databricks environments [Slack thread](https://slack.com/archives/C02CTC89LAX/p1692603763973949). Summary: - The existence of the base tables is necessary, but not always sufficient if the issue is with temp view lifecycle or session management. - This is a known, sometimes intermittent issue, especially on Databricks/Spark. - Upgrading Elementary, using fresh clusters, or ensuring no concurrent runs may help, but there is no guaranteed fix documented in the knowledge sources for all environments. If you are already on the latest version and using a fresh cluster, and the problem persists, it may be an unresolved edge case in Elementary’s handling of temp views on your platform. The knowledge sources do not provide a definitive solution beyond these recommendations.
a
this is the error @kapa.ai Too many tables, views and user-defined functions for query: Max: 1000
k
A message from kapa.ai
The error "Too many tables, views and user-defined functions for query: Max: 1000" is a known issue when using Elementary, especially in environments with a large number of tests or models. This happens because Elementary creates a temporary table for every test, and if you have many tests, you can quickly hit the warehouse's limit on the number of tables or views referenced in a single query. Key points from the knowledge sources: - Elementary creates a temp table for every test with its relevant data. If you have a lot of tests, this can cause the number of tables in your schema to grow rapidly and hit platform limits, such as BigQuery's or other warehouses' maximum number of tables/views per query or per schema. - There is currently no built-in automation in Elementary to delete these temp tables after the run. The recommended workaround is to manually delete these tables at the end of each run, or script their deletion as part of your workflow. - This issue has been reported by other users, and downgrading to an earlier version of Elementary (before the change that caused excessive temp table creation) has been used as a temporary fix by some. However, this is not ideal for most teams. - The Elementary team is aware of the issue and has mentioned that a solution (such as automatic cleanup of temp tables) is pending, but as of the latest knowledge sources, it is not yet available [Slack thread](https://slack.com/archives/C02CTC89LAX/p1695829358965979), [Slack thread](https://slack.com/archives/C02CTC89LAX/p1689292849785299). What you can do: - Manually delete temp tables after your dbt/Elementary run completes. - Monitor the number of tests you are running, as each test creates a temp table. - Watch for updates from Elementary for a more permanent fix regarding temp table cleanup. If you are running into this error frequently, consider scripting the cleanup of these temp tables as part of your workflow until an official solution is released. If you need more specific guidance on how to script the cleanup, please let me know your data warehouse platform, and I can provide an example based on the knowledge sources.
a
can you change the expiration_timestamp on the table? @kapa.ai
k
A message from kapa.ai
Yes, you can set the 
expiration_timestamp
on temporary tables in BigQuery. In fact, Elementary already creates temporary tables with an 
expiration_timestamp
set to 12 hours from creation by default, as seen in the following example:
Copy code
sql create or replace table `project-id`.`elementary`.`data_monitoring_metrics__tmp_20230807132124986186`     OPTIONS(       expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 12 hour)     )     as (       ...     )
However, according to user reports, changing the expiration time via the 
hours_to_expiration
parameter in 
dbt_project.yml
does not affect these temporary tables—only the non-temporary tables are affected by this setting. Users have noted that attempts to set a custom expiration for these temp tables were unsuccessful, and this behavior has been acknowledged by the Elementary team. They have also mentioned working on a fix to improve temp table cleanup in future releases [Slack thread](https://slack.com/archives/C02CTC89LAX/p1684349983650899). Summary: - Elementary sets a default expiration of 12 hours for temp tables in BigQuery. - The 
hours_to_expiration
config does not currently change this for temp tables. - There is no documented way (as of the latest knowledge sources) to customize the expiration timestamp for these temp tables via Elementary configuration.
a
why does chunking not help with the temp table issue @kapa.ai
k
A message from kapa.ai
Chunking (using 
insert_rows_method: chunk
and setting 
dbt_artifacts_chunk_size
) helps Elementary avoid database errors related to query size or the number of rows inserted in a single statement. It works by splitting large insert operations into smaller batches, which can prevent issues like exceeding query length or row limits during artifact uploads. However, chunking does not address the temp table issue because the problem is not with the size of the insert statements, but with the sheer number of temporary tables Elementary creates—one for each test. When you have a large number of tests, this can quickly exceed your data warehouse’s limit on the number of tables, views, or user-defined functions referenced in a single query or schema (for example, BigQuery’s 1000-table limit per query). The knowledge sources confirm that: - Chunking is designed to help with query complexity and size, not with the number of temp tables created. - The temp table issue arises because Elementary creates a temp table for every test, and there is currently no built-in automation to clean them up after the run. This leads to schema bloat and can cause failures when the warehouse’s object limits are reached, regardless of chunking settings [Slack thread](https://slack.com/archives/C02CTC89LAX/p1695829358965979), [Slack thread](https://slack.com/archives/C02CTC89LAX/p1689292849785299). In summary: Chunking helps with query size and complexity, but does not reduce the number of temp tables created. The temp table issue is a separate limitation, and chunking does not mitigate it.
a
what does columns_upload_strategy: none do ?
what does columns_upload_strategy: none do ? @kapa.ai
k
A message from kapa.ai
Setting 
columns_upload_strategy: none
in your 
dbt_project.yml
disables the upload and collection of column metadata by Elementary. This means that the 
dbt_columns
table will not be populated or updated, which can help reduce memory consumption and speed up runs, especially in environments where updating column metadata is resource-intensive or causes issues (such as exceeding query length limits in Athena or high memory usage). This setting is recommended by Elementary support as a workaround for performance and resource issues related to the 
dbt_columns
table. When set to 
none
, Elementary will skip the process of collecting and uploading column information, but other features like reports and alerts will continue to work as usual, except for those that rely on column metadata. If you still need to run Elementary but want to avoid the overhead of column collection, this is the appropriate configuration to use [Slack thread](https://slack.com/archives/C02CTC89LAX/p1740143298724479) [Slack thread](https://slack.com/archives/C02CTC89LAX/p1741597159468009).
a
will that improve the imports into the data_monitoring_metrics? @kapa.ai
k
A message from kapa.ai
Setting 
columns_upload_strategy: none
specifically disables the upload of column metadata to the 
dbt_columns
table. According to the knowledge sources, this setting is helpful for reducing memory consumption and avoiding issues related to the 
dbt_columns
model, such as long run times or exceeding query length limits—especially in environments like Athena or with large projects [Slack thread](https://slack.com/archives/C02CTC89LAX/p1741597159468009). However, there is no direct evidence in the knowledge sources that setting 
columns_upload_strategy: none
will improve the performance of imports into the 
data_monitoring_metrics
table. The two processes are separate: disabling column uploads affects only the collection and upload of column metadata, not the metrics collection or import process for 
data_monitoring_metrics
. In summary: Disabling column uploads may improve overall resource usage and avoid issues related to the 
dbt_columns
table, but there is no information in the knowledge sources indicating it will directly improve imports into 
data_monitoring_metrics
.
a
@kapa.ai but will it help to avoid the Too many tables, views and user-defined functions for query: Max: 1000 Error i'm seeing when elementary tries to create or replace table 
msm-groupdata-cdm-explore
.
anna_elementary
.
data_monitoring_metrics__tmp_20250515115619038995
k
A message from kapa.ai
Setting 
columns_upload_strategy: none
will not help you avoid the "Too many tables, views and user-defined functions for query: Max: 1000" error when Elementary tries to create or replace a table like 
data_monitoring_metrics__tmp_...
. This error occurs because Elementary creates a temporary table for each test, and if you have a large number of tests, you can quickly exceed your data warehouse's limit on the number of tables or views referenced in a single query or schema. Disabling column uploads only affects the collection and upload of column metadata to the 
dbt_columns
table, not the creation of temp tables for test results or metrics. The temp table issue is unrelated to the column upload process and is a separate limitation that chunking or disabling column uploads does not address [Slack thread](https://slack.com/archives/C02CTC89LAX/p1695829358965979), [Slack thread](https://slack.com/archives/C02CTC89LAX/p1689292849785299). In summary: 
columns_upload_strategy: none
will not resolve the "Too many tables, views and user-defined functions" error. The root cause is the number of temp tables created by Elementary, not the column upload process.
a
how come you suggested the chunking in the past? @kapa.ai and why is it different from this error?
k
A message from kapa.ai
Great question! Chunking (using 
insert_rows_method: chunk
and setting 
dbt_artifacts_chunk_size
) is often suggested because it helps address **query size and complexity errors**—for example, when a single insert statement generated by Elementary is too large or too complex for the data warehouse to process. This is a common issue in BigQuery and Snowflake, where there are strict limits on query length, the number of subqueries, or the number of rows inserted at once. Chunking splits large insert operations into smaller, more manageable queries, which can help avoid errors like "query too complex" or "query too large" [Slack thread](https://slack.com/archives/C02CTC89LAX/p1688993823760889), [GitHub Issue #1689](https://github.com/elementary-data/elementary/issues/1689). However, the error "Too many tables, views and user-defined functions for query: Max: 1000" is different. This error is caused by the **number of tables or views referenced in a single query**—not the size or complexity of the query itself. Elementary creates a temporary table for each test, and if you have a large number of tests, you can exceed your data warehouse's limit on the number of tables/views/functions in a single query or schema. Chunking does not reduce the number of temp tables created; it only affects how data is inserted into those tables [Slack thread](https://slack.com/archives/C02CTC89LAX/p1695829358965979). In summary: - Chunking helps with query size/complexity errors. - The "Too many tables/views" error is about the number of objects referenced, which chunking does not address. That’s why chunking is helpful for some errors, but not for the specific "Too many tables, views and user-defined functions" error you’re seeing.
a
@kapa.ai can you show me the two different errors fully?
k
A message from kapa.ai
Certainly! Here are the two different errors as they appear in the knowledge sources: --- ### 1. Query Size/Complexity Error (Chunking Can Help) This error typically appears as:
Copy code
Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex.
This error is related to the size or complexity of a single query, such as when an insert statement is too large or contains too many subqueries. Chunking is often suggested as a solution for this error, as it breaks large queries into smaller ones, making them more manageable for the data warehouse to process [Slack thread](https://slack.com/archives/C02CTC89LAX/p1677869503258149). --- ### 2. Too Many Tables/Views Error (Chunking Does Not Help) This error appears as:
Copy code
Too many tables, views and user-defined functions for query: Max: 1000
This error is caused by exceeding the data warehouse's limit on the number of tables, views, or user-defined functions referenced in a single query. It often occurs when Elementary creates a temporary table for each test, and the total number exceeds the warehouse's limit. Chunking does not address this error, as it does not reduce the number of tables or views created or referenced [Slack thread](https://slack.com/archives/C02CTC89LAX/p1695829358965979). --- If you need more details or examples from the sources, let me know!
a
and even if I run this on a separate dbt run @kapa.ai will it still cause me errors ? so even if i do new test does this collate every single test that is in the table?
k
A message from kapa.ai
If you run your tests in a separate 
dbt run
, the error can still occur if the Elementary schema already contains a large number of temp tables from previous runs. Elementary’s process does not just consider the tests in your current run—it can reference or be affected by all temp tables present in the schema. This means that even if you only run a new test, if the schema already has many temp tables (from previous or concurrent runs), you can still hit the "Too many tables, views and user-defined functions for query: Max: 1000" error. This is confirmed by user reports stating that the accumulation of temp tables in the schema (not just from the current run) leads to hitting the warehouse object limit, and that manual cleanup or downgrading was required to avoid the error. The Elementary team has acknowledged that there is currently no built-in automation for deleting these temp tables, so they can accumulate over time and cause issues regardless of how you structure your runs [Slack thread](https://slack.com/archives/C02CTC89LAX/p1695829358965979), [Slack thread](https://slack.com/archives/C02CTC89LAX/p1689292849785299). In summary: - Yes, the error can still happen even in a new or separate run if the schema already contains many temp tables. - The process is affected by the total number of temp tables in the schema, not just those created in the current run. - Manual cleanup of temp tables is currently the only workaround to prevent this error.
a
if I disable the test results will that stop it ? @kapa.ai
k
A message from kapa.ai
Yes, disabling test results will stop Elementary from creating the temporary tables for test results, which are the source of the "Too many tables, views and user-defined functions for query" error. When you set the variable 
disable_tests_results: true
, Elementary will not process or upload test results, and therefore will not create the associated temp tables for those results. This is confirmed in the documentation and community discussions about controlling which artifacts Elementary uploads and how to avoid issues related to temp table accumulation [Can I disable the on-run-end hooks?](https://docs.elementary-data.com/dbt/on-run-end_hooks#can-i-disable-the-on-run-end-hooks%3F). So, if you set:
Copy code
yaml vars:   disable_tests_results: true
Elementary will skip the test results upload step, and the temp tables for test results will not be created, which should prevent this specific error from occurring.
29 Views
Open in Slack
PreviousNext
Powered by