An ETL warehouse is already configured as a multi-cluster warehouse that scales between one and six clusters. One nightly transformation query joins billions of rows and runs too slowly, even on a night when it is the only query on the warehouse and only one cluster is ever started. An engineer proposes simply raising the maximum cluster count so the query can use more clusters. Why will raising the maximum cluster count fail to make this single query run faster?
- AAdditional clusters in auto-scale mode only start when the scaling policy is set to Economy, so the existing Standard policy blocks them from ever helping the slow nightly query
- BA single query executes within one cluster, and every cluster in a multi-cluster warehouse is the same size, so more clusters add concurrency capacity but never more compute to one query Correct
- CExtra clusters would start, but Snowflake splits the single query evenly across all running clusters, which adds network shuffle overhead that cancels out the extra compute it gains
- DThe maximum cluster count is ignored at night because auto-suspend has already powered the warehouse down, so the extra clusters cannot be provisioned while the query waits to resume
Why A is wrong: Both Standard and Economy policies can start extra clusters when queuing occurs, so the policy is not the reason, and extra clusters still could not accelerate a single query anyway.
Why B is correct: Multi-cluster warehousing scales out for concurrency, and one query is confined to a single same-sized cluster, so only scaling up to a larger size adds memory and compute to that query.
Why C is wrong: Snowflake never spreads one query across multiple clusters of a multi-cluster warehouse, so there is no cross-cluster shuffle, and the stated overhead mechanism does not occur.
Why D is wrong: Auto-suspend stops an idle warehouse but a submitted query auto-resumes it, and once running the cluster limit still applies, so suspension is not why extra clusters fail to help.