•

Snowflake Performance and Tuning: 9%

The best method to assist pruning on a large table is to:

• Create a CLUSTERED INDEX on the table

• Define a PARTITIONING KEY on the table

• Create a DENSE INDEX on the table

• Define a CLUSTER KEY for the table

• Define a HASH TABLE for the table

If a query is slow, how can the query be changed to improve the query?

• Reorder the list of tables in the query to change the order the tables are read in the query.

• If possible, use the table’s defined CLUSTER KEY in the query

• Change the order of the where clause to force the optimizer to consider the most effective filter
first.

• Provide a hint to the optimizer

• Use an ORDER BY on the query to order the data before it’s searched

How is the most effective way to test if clustering a table helped performance?

• Use SYSTEM$CLUSTERING_INFORMATION. Check the total_constant_partition_count.

• Use SYSTEM$CLUSTERING_INFORMATION. Check the average_overlaps.

• Run a sample query before clustering and after to compare the results.

• Use SYSTEM$CLUSTERING_INFORMATION. Check the average_depth

• Use the SYSTEM$CLUSTERING_DEPTH and check the depth of each column.

The BI group is complaining about their queries taking too long to run. Checking the virtual warehouse
information shows the queued time is pretty high. What is the best way to fix this issue?

• Provide a virtual warehouse for every user in the group

 • Increase the size of the virtual warehouse

• Determine which users have the high priority queries and set the other users

• STATEMENT_QUEUED_TIMEOUT_IN_SECONDS parameter to a low value to cancel those queries

if they get in the queue.

• Increase the virtual warehouse MAX_CLUSTER_COUNT property

• Increase the virtual warehouse MAXCONCURRENCY_LEVEL parameter

In the History Page, a query shows Bytes Scanned having Assigned Partitions: 110, Scanned Partitions
58, and Original Partitions 110. Why did the optimizer show fewer partitions scanned than assigned?

• One of the tables in the query was an external table and didn’t have micro partitions The
metadata for the table was out of date and there were really only 58 partitions total.

• The query was using an Xlarge warehouse and could scan the partitions in parallel

• During the execution of the query, new data was added to the table and the optimizer had to
add those micro partitions into the scan.

• The optimizer estimated only 58 partitions would need to be scan but during the execution of
the query, the optimizer realized it would have to read all 110 micro partitions

• The static optimization determined the number of possible micro partitions would be 110 but
the dynamic optimization was able to prune some of the partitions from a joined table