Changelog

We're excited to announce our brand new query page, containing SELECT's very own custom query profile. Users can now investigate query performance bottlenecks and access detailed query statistics, all without leaving the app.

The first version of the query profile we've released contains some subtle usability improvements, but largely has the same look and feel as Snowflake's query profile. Stay tuned for future updates where we'll add some powerful new capabilities!

The feature is powered by Snowflake's new get_query_operator_stats which provides programmatic access to the query profile. A big thanks to the team at Snowflake for releasing this functionality and enabling partners to build these new capabilities.

With our new support for Custom Workloads, users can now tag queries with a supported schema and gain access to a comprehensive dashboard to slice by a variety of useful dimensions, and drill into individual workload’s cost, performance and execution history.

Refer to our documentation for more details on how you can leverage the Custom Workloads feature.

We’re excited to announce Looker support, our first business intelligence (BI) tool integration. As BI tooling can drive significant Snowflake usage, it’s important to understand the cost each dashboard's queries in these tools.

The Looker integration attributes query costs to dashboards.

Use the query timeline view to understand performance bottlenecks or costly queries, or leverage the Cost and Performance tabs to see how dashboard usage statistics have been trending. On the Run History tab, you’ll see a complete history of all dashboard runs including which user triggered the run and any error messages they saw.

Follow our Looker setup instructions to configure the integration in less than 10 minutes.

To help with monitoring performance and understanding the impact of warehouse or query changes, we’ve added three new capabilities to the warehouse performance tab.

Monitor a larger variety of aggregation types (avg, p50 through p99) across any metric.

Analyze query times with any aggregation type (min, max, avg, p50 through p99).

Monitor query result cache usage rates to better understand performance.

On the warehouse performance tab, we’ve included two new views to help with warehouse sizing:

1. The number of queries by execution time. Here you can see that over 98% of the queries running on this warehouse are taking less than 1 second to execute.
2. The number of queries by utilizable warehouse size. Utilizable warehouse size represents the size of warehouse a query can fully utilize. The value is always capped at the query's current warehouse size. Where lots of queries don't utilize the warehouse's size, it indicates that the warehouse is oversized or the queries should run on a smaller warehouse. In this example, over 96% of queries being run on the warehouse aren’t using all 8 nodes available in the warehouse.

To further facilitate identifying workloads and queries of interest, we’ve made all tables in the product sortable. Sort by executions to identify high frequency queries, or by change to identify the workloads with the largest cost fluctuation.

For customers with a large number of users or warehouses in their Snowflake account, finding individual selections can become time consuming.

To enable quick filtering, we’ve added a search parameter to the dropdown filters.

Individuals are now able to invite teammates to SELECT via email directly in the product. Individual user access can now be disabled as well. To access this functionality, click the “Invite a teammate” button in the bottom left or visit the settings page.

Staying on top of your Snowflake usage can be hard. To help you more easily keep an eye on your spend trends, we created Slack spend digests. Spend digests are a daily/weekly/monthly Slack message you can enable in settings. They are designed to help you easily keep tabs on your Snowflake spend, see if anything spiked, and understand what caused the spike if so.

Here’s a recent example of the daily spend digest for our Snowflake account:

Anytime something spikes, you can click straight into the relevant section of the SELECT web app (i.e. the warehouse page) and understand what drove the increase (or decrease 🤞).

Wherever possible, we strive for everything you need to be 1-click away. To help streamline spend investigations, we’ve added new links to the “Spend by User” and “Spend by Database” charts.

In the example below, you can see me figure out what expensive queries Niall was running in the last two weeks, and dive into the most expensive tables in our development environment.

When changing from a daily to weekly/monthly date grain, we now automatically adjust the date range to only include complete weeks/months. This is helpful to avoid having an incomplete time period, which can be very misleading.

On the dbt workloads page, you’ll see a new spend overview chart at the top breaking down your dbt spend. Similar to the workloads table, a period over period change is shown allowing you to quickly spot models that spiked, or new ones that shipped. The full run history for each dbt model is also now available, which links out to a dedicated page for each dbt run.

Demo

You can see all this new functionality in action as I investigate a recent spike in our dbt spend:

• I zoom into the spike on March 11
• I see that the query_history_enriched_select model had a huge increase in costs that day
• After opening up that model page, I click on the new “Run History” tab
• I see that there were a bunch of full refreshes, including many that failed
• I click one of the failed runs which takes me to the new “dbt Run” page
• Here I can see the exact SQL ran, which step of the model failed and all relevant execution details

We’ve added a new “Change” column to all workload views, making it even easier to figure out what caused your spend to change. In the example below, I zoom into a period on our SELECT_BACKEND warehouse and can easily see which workloads spiked and which new workloads were introduced.