In Snowflake, how does partition pruning contribute to optimizing query performance?

Question

Options

• AImpacts query planning but not execution
• BLimits data accessibility across warehouses
• CFilters unnecessary partitions during query execution
• DIncreases query complexity and optimization

• A
  2% (1)
• B
  4% (2)
• C
  89% (48)
• D
  6% (3)

Explanation

Partition pruning in Snowflake works by analyzing query predicates (like WHERE clauses) at execution time to skip micro-partitions that cannot contain relevant data, drastically reducing I/O and speeding up queries. Option C is correct because pruning is an active execution-time optimization - Snowflake reads partition metadata to physically bypass irrelevant data blocks before scanning.

Why the distractors are wrong:

• A is wrong because pruning absolutely affects execution (not just planning) - it determines which micro-partitions are actually read from storage.
• B is wrong because pruning has nothing to do with cross-warehouse data access; it operates within a single query's scan scope.
• D is wrong because pruning reduces complexity and resource usage - it is a simplification mechanism, not a complication.

Memory tip: Think of partition pruning as a "smart skip list" - Snowflake checks each micro-partition's min/max metadata and skips any partition that can't match your filter, like skipping chapters in a book that can't contain what you're looking for.

No community discussion yet for this question.