Notes de version 9.20 : 21 juillet 2025 - 25 juillet 2025¶

La commande CREATE INDEX prend en charge les colonnes INCLUDE¶

Avec cette version, vous pouvez utiliser la commande CREATE INDEX pour créer des index secondaires avec les colonnes INCLUDE. Dans les versions précédentes, les colonnes INCLUDE n’étaient prises en charge que pour les index secondaires définis dans les instructions CREATE HYBRID TABLE.

Vues sémantiques : Répertorier les dimensions et les métriques dans une vue, un schéma, une base de données ou un compte¶

Pour répertorier les dimensions et les métriques dans une vue sémantique, un schéma, une base de données ou un compte, exécutez les commandes suivantes :

• SHOW SEMANTIC DIMENSIONS

• SHOW SEMANTIC METRICS

Vous pouvez également répertorier les dimensions que vous pouvez spécifier lors de la requête d’une métrique spécifique. Lorsque vous spécifiez une dimension et une métrique dans une requête, la table de base de la dimension doit être liée à la table de base de la métrique. En outre, la table de base de la dimension doit avoir un niveau de granularité égal ou inférieur à celui de la table de base de la métrique.

Par exemple, l’exemple suivant interroge la vue tpch_analysis et renvoie la métrique customer_order_count et la dimension order_date :

SELECT * FROM SEMANTIC_VIEW (
  tpch_analysis
  DIMENSIONS orders.order_date
  METRICS customer.customer_order_count
);

Cette requête échoue car la table orders de la dimension a un niveau de granularité supérieur à celui de la table customer de la métrique :

010234 (42601): SQL compilation error:
Invalid dimension specified: The dimension entity 'ORDERS' must be related to and
have an equal or lower level of granularity compared to the base metric or dimension entity 'CUSTOMER'.

Pour répertorier les dimensions dont les tables de base sont liées à la table de base d’une métrique et ont un niveau de granularité égal ou inférieur à celui-ci, exécutez la commande SHOW SEMANTIC DIMENSIONS FOR METRIC. Par exemple :

SHOW SEMANTIC DIMENSIONS IN tpch_analysis FOR METRIC customer_order_count;

Nouvelles informations de requête sur les performances et l’optimisation des jointures¶

La vue QUERY_INSIGHTS inclut désormais des informations sur les conditions suivantes qui ont pu affecter les performances des requêtes :

• Une requête ou une sous-requête ne comporte pas de clause WHERE, ce qui signifie que la requête analyse l’intégralité d’une table et peut renvoyer plus de lignes que prévu.

• Une jointure qui inclut le résultat d’au moins une autre jointure renvoie beaucoup plus de lignes que les tables jointes.

• Une jointure de deux ensembles de données (par exemple, des tables, des vues ou le résultat d’appels de fonctions de table) renvoie beaucoup plus de lignes que les tables jointes.

• Les performances d’une requête ont été améliorées grâce à l’optimisation de la recherche.

Chaque information comprend un message qui explique comment les performances de la requête ont pu être affectées et fournit une recommandation générale pour les étapes suivantes.

Pour plus d’informations, voir Utilisation des insights de requêtes pour améliorer les performances.

Tâches : Nouvelle option EXECUTE AS USER et privilège IMPERSONATE pour les objets utilisateur¶

Avec cette version, les organisations qui attribuent des privilèges de sécurité Snowflake par utilisateur peuvent autoriser les utilisateurs à exécuter des tâches d’équipe à l’aide de leurs comptes utilisateur existants.

Nous recommandons aux équipes de créer un utilisateur de service qui représente une équipe et d’attribuer les privilèges requis à cet utilisateur. Vous pouvez ensuite utiliser GRANT IMPERSONATE ON USER <user_name> TO ROLE <role_name> pour accorder aux utilisateurs des privilèges leur permettant de créer ou de modifier des tâches en fonction du compte utilisateur de l’équipe. Les utilisateurs individuels peuvent alors exécuter des tâches au nom de l’utilisateur de l’équipe afin d’utiliser leurs privilèges avec les nouveaux paramètres : CREATE TASK … EXECUTE AS USER <user_name> et ALTER TASK … EXECUTE AS USER <user_name>.

Pour plus d’informations, voir Exécuter des tâches avec des privilèges d’utilisateur.

Tables dynamiques : Utilisation non autorisée de l’attribut COPY_SESSION lors de l’actualisation manuelle de tables dynamiques sur un entrepôt sans serveur¶

L’utilisation de COPY_SESSION avec une table dynamique dans un contexte sans serveur entraîne l’héritage de l’entrepôt sans serveur lors de l’actualisation, ce qui conduit à un comportement non pris en charge et indéfini. Cette configuration entraîne désormais une erreur.

Pour plus d’informations, voir REFRESH [ COPY SESSION ].