Hello 👋 We have been running elementary 0.7.1 and have recently experienced issues in our dbt cloud daily runs which end up in error:

This run exceeded your account's run memory limits.

The error is returned at the elementary's on-run-end hook. dbt support, after having inspected logs, tells me that the peak memory usage occurs at this stage (that is in a successful run):

2024-01-22 00:02:13.484827 (MainThread): 00:02:13  On master: /* {"app": "dbt", "dbt_version": "1.7.5", "profile_name": "user", "target_name": "prod", "connection_name": "master"} */
select artifacts_model, metadata_hash from "CUSTOM"."DBT_METADATA"."DBT_ARTIFACTS_HASHES"
    order by metadata_hash
2024-01-22 00:02:19.299083 (MainThread): 00:02:19  SQL status: SUCCESS 9460703 in 6.0 seconds

Is it necessary for elementary to retrieve all results from

DBT_ARTIFACTS_HASHES

table which is currently >9M rows and growing? Can this behavior be disabled?

hey @Magdalena Paszko; we're also experiencing the exact same issue at a client of ours. Were you able to resolve this?

Hey @Magdalena Paszko, sorry for the late response! It seems like you are running a very old version of elementary (we currently at 0.14.X). A lot of changes has been made since that version including performance improvements so that might be solved in our latest version. Care to give it a try and update if yo still having this issue? In addition in order to disable the artifacts cache, you can set the var

cache_artifacts

to

false

. This should disable the use of

DBT_ARTIFACTS_HASHES

version: 0.10.0

😐

So I suggest here as well to try and update the version of elementary and see if that helps 🙂 If not, share with us the logs and errors they have so we could try and solve this issue!

let me double-check if upgrading is a viable option. while i do that i might try your fix above about setting

cache_artifacts

to false to help unblock the devs. thanks @Idan Shavit

NP! Waiting for your input 🙂

without sharing too much sensitive info, here's the dbt-log where it fails:

{"data": {"conn_name": "master", "sql": "/* {\"app\": \"dbt\", \"dbt_version\": \"1.4.7\", \"profile_name\": \"\", \"target_name\": \"main\", \"connection_name\": \"master\"} */\n\n    \n    select artifacts_model, metadata_hash from `dbt_artifacts_hashes`\n    order by metadata_hash\n    \n  "}, "info": {"category": "", "code": "E016", "extra": {}, "invocation_id": "110fa9cd0e64", "level": "debug", "msg": "On master: /* {\"app\": \"dbt\", \"dbt_version\": \"1.4.7\", \"profile_name\": \"\", \"target_name\": \"main\", \"connection_name\": \"master\"} */\n\n    \n    select artifacts_model, metadata_hash from `dbt_artifacts_hashes`\n    order by metadata_hash\n    \n  ", "name": "SQLQuery", "pid": 65, "thread": "MainThread", "ts": "2024-03-07T03:39:07.479813Z"}}
{"data": {"args": [], "base_msg": "<https://console.cloud.google.com/bigquery?&page=queryresults>", "name": "BigQuery", "node_info": {"materialized": "view", "meta": {}, "node_finished_at": null, "node_name": "elementary-on-run-end-0", "node_path": "hooks/elementary-on-run-end-0.sql", "node_started_at": "2024-03-07T03:39:07.194317", "node_status": "started", "resource_type": "operation", "unique_id": "operation.elementary.elementary-on-run-end-0"}}, "info": {"category": "", "code": "E001", "extra": {}, "invocation_id": "110fa9cd0e64", "level": "debug", "msg": "BigQuery adapter: <https://console.cloud.google.com/bigquery?5&page=queryresults>", "name": "AdapterEventDebug", "pid": 65, "thread": "MainThread", "ts": "2024-03-07T03:43:55.284414Z"}}

Hi. Sorry for late reply. In fact it was due to our internal customization implemented to the package. Instead of fully replacing the artefact tables with each run, we accumulate them with every invocation in order to track the state of our project over time (how many models. tests etc. we've had over time).

DBT_ARTIFACTS_HASHES

view has accumulated rows accordingly and this caused the memory explosion. So I just customized the view definition to only return artefacts from the most recent invocation. Still - I would like to understand what this

DBT_ARTIFACTS_HASHES

view does but I find no information in Elementary documentation. What is its role in collecting the run results?