Isaac S.

André M. Happy to help! COMMENT ON COLUMN replaces that table's catalog entry and bumps the database's catalog version, which leaves the client's cached catalog stale. The client rebuilds the full catalog every column write. With no multi column form, that's 20 rebuilds for 20 columns. The transaction helps because in auto-commit, each statement needs a second round trip to fetch the new catalog. In a transaction the server sends it along with the statement itself which saves a roundtrip per comment. The rebuilds still happen per statement though, which is why you saw an improvement rather than it collapsing to a single commit. For now, if you have persist_docs enabled, setting columns:false keeps your model-level descriptions while dropping one statement per column. If you want to keep column-level descriptions, scoping them to your marts and leaving them off staging may help: docs.getdbt.com/reference/resource-configs/persist_docs The rebuild cost should track the size of that database's catalog rather than the comment itself, so it'd help to know which database you benchmarked against and roughly how many tables it has. Let me know if anything's unclear. I'll see what more we can do on our side and get back to you.

Sahil G. Hello! We've fixed this issue in our latest release. Can you confirm on your end that you can hit close without zooming out, and that the Guides pop-up X's out while the upload modal is open?

Hi Marin Š. Our MotherDuck release is out! Can you retry running your flight and let me know if its working?

Happy to help! Let us know if you anything else comes up.

HI Greg, Confirmed, the UI was showing your configured size, but the swap to a standard duckling hadn't happened yet. The running Duckling isn't replaced until it clears a window of inactivity. To force it to swap, you can run the SQL command SHUTDOWN or Reset Ducklings in the UI. That ends the current Duckling so the new size take effect on your next query instead of waiting on cooldown. The gap between the configured size and the Duckling actually running isn't visible anywhere today. I'll pass this along to our UI team and I'll follow up with you if anything changes.

Hi Greg O. Our logs show the initial delete hit an out-of-memory error before it could commit. Moving to Standard raised the memory limit but kept the same duckling running, so the retries failed on leftover state from that first attempt rather than on memory. It went through once you landed on a fresh duckling about an hour later. Going forward: and unqualified DELETE FROM holds deletion bookkeeping for every row in a single transaction, so chunking it with a commit per chunk, like you did in your later DML queries, keeps memory use flat not matter how large the table gets. If a write does fail, SHUTDOWN cycles the duckling before you retry, especially if you've upgraded the duckling size in between. docs here

Hi Sahil, thanks for sharing this screen recording. We'll pass this along to our UI team and follow up if anything changes.

Hey Sahil G., Thanks for flagging both of these. Would you be able to share a screenshot or a short screen recording of what you're seeing?