Versions de l'optimiseur de requêtes Spanner

Cette page décrit les différentes versions de l'optimiseur de requêtes Spanner et fournit leur historique. La version par défaut actuelle est la version 8. Pour en savoir plus sur l'optimiseur de requêtes, consultez la présentation de l'optimiseur de requêtes.

Spanner déploie les mises à jour de l'optimiseur de requêtes en tant que nouvelles versions de l'optimiseur de requêtes. Par défaut, chaque base de données commence à utiliser la dernière version de l'optimiseur au plus tard 30 jours après sa publication.

Vous pouvez gérer la version de l'optimiseur de requêtes que vos requêtes utilisent pour les bases de données avec dialecte GoogleSQL et PostgreSQL. Avant de procéder au commit vers la dernière version, vous pouvez comparer les profils de performances des requêtes entre les anciennes versions et la dernière version. Pour en savoir plus, consultez la page Gérer l'optimiseur de requêtes.

Historique des versions de l'optimiseur de requête

Vous trouverez ci-dessous un récapitulatif des mises à jour apportées à l'optimiseur de requêtes dans chaque version.

Version 9 : 21 juillet 2026 (dernière version)

  • Améliore l'efficacité des jointures d'application distribuée (DA) en n'envoyant que les colonnes requises de l'entrée vers le côté mappage de la jointure.

  • Sélectionne automatiquement les index sur les colonnes calculées lorsque la même expression calculée est une condition de filtre ou de jointure dans une requête.

    Par exemple, permet de sélectionner l'index sur Singers((LOWER(FirstName))) s'il est présent pour la requête suivante :

    GoogleSQL 

    SELECT s.SingerId, s.FirstName, s.LastName
FROM Singers s
WHERE LOWER(s.FirstName) > 'k'
LIMIT 10;

    PostgreSQL 

    SELECT s.singerid, s.firstname, s.lastname
FROM singers s
WHERE LOWER(s.firstname) > 'k'
LIMIT 10;

  • Améliore les performances de recherche d'index entrelacé en regroupant et en triant les clés pour des recherches séquentielles efficaces dans le stockage.

  • Légères améliorations apportées à l'estimation de la cardinalité.

  • Préfère de manière heuristique les plans avec application distribuée plutôt qu'une application avec union distribuée du côté mappage s'il n'y a pas de LIMIT au-dessus de l'application.

  • Choisit les plans d'union d'index de manière plus agressive.

  • Améliore les performances de GROUP BY en étendant l'agrégation basée sur l'analyse pour prendre en charge les prédicats de filtre où la clé d'agrégation est comparée à des fonctions impliquant des constantes et des paramètres.

  • Active l'optimisation du plan basée sur les coûts pour les requêtes impliquant des tables avec des schémas nommés.

Version 8 : 28 octobre 2024 (par défaut)

  • Les clauses WITH sont prises en compte lors du choix d'un plan basé sur les coûts.

  • Amélioration des performances des requêtes d'application croisée distribuée et de recherche indexée.

  • Amélioration du réordonnancement JOIN.

  • Amélioration des performances des requêtes avec de grandes clauses IN (...).

  • Amélioration des performances de GROUP BY dans certains cas.

  • Autres améliorations, y compris une gestion plus efficace des requêtes avec LIMIT, des clés étrangères et de la sélection d'index.

Version 7 : 22 mai 2024

  • Ajout de la prise en charge de la sélection basée sur les coûts des plans d'union d'index.

  • Ajout de la prise en charge de la sélection intelligente des plans de recherche par rapport aux plans d'analyse en fonction des statistiques pour les requêtes qui ne comportent pas de prédicats pouvant être recherchés pour toutes les parties clés.

  • Ajout de la prise en charge de la sélection basée sur les coûts des jointures de hachage.

Version 6 : 11 septembre 2023

  • Amélioration du pushdown de limite et du pushdown de prédicat via des jointures externes complètes.

  • Amélioration de l'estimation de la cardinalité et du modèle de coûts.

  • Activation de l'optimisation basée sur les coûts pour les requêtes LMD.

Version 5 : 15 juillet 2022

  • Amélioration du modèle de coûts pour la sélection d'index, la gestion de la distribution, le placement du tri et la sélection GROUP BY.

  • Ajout de la prise en charge de la sélection d'algorithmes de jointure basée sur les coûts, qui choisit entre la jointure de hachage et la jointure d'application. La jointure par fusion nécessite toujours l'utilisation d'une optimisation de requête.

  • Ajout de la prise en charge de la commutativité des jointures basée sur les coûts.

Version 4 : 1er mars 2022

  • Améliorations apportées à la sélection d'index secondaires.

    • Amélioration de l'utilisation d'index secondaires dans une jointure entre des tables entrelacées.
    • Amélioration de l'utilisation d'index secondaires de couverture.
    • Amélioration de la sélection d'index lorsque les statistiques de l'optimiseur sont obsolètes.
    • Préfère les index secondaires avec des prédicats sur les colonnes indexées principales, même si les statistiques de l'optimiseur ne sont pas disponibles ou indiquent que la table de base est petite.

  • Introduit la jointure de hachage en une seule passe, activée par la nouvelle optimisation hash_join_execution.

    Optimisation de jointure :

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=hash_join, hash_join_execution=one_pass} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=hash_join, hash_join_execution=one_pass */ (...)

    Le nouveau mode est avantageux lorsque l'entrée du côté compilation de la jointure de hachage est volumineuse. La jointure de hachage en une seule passe devrait être plus performante lorsque vous observez les éléments suivants dans le profil d'exécution de la requête :

    • Le nombre d'exécutions sur l'enfant de droite de la jointure de hachage est supérieur au nombre d'exécutions sur l'opérateur de jointure de hachage.
    • La latence sur l'enfant de droite de l'opérateur de jointure de hachage est également élevée.

    Par défaut (hash_join_execution=multi_pass), si l'entrée du côté compilation de la jointure de hachage est trop volumineuse pour tenir en mémoire, le côté compilation est divisé en plusieurs lots et nous pouvons analyser le côté vérification plusieurs fois. Avec le nouveau mode (hash_join_execution=one_pass), une jointure de hachage est déversée sur le disque si son entrée du côté compilation ne peut pas tenir en mémoire et analyse toujours le côté vérification une seule fois.

  • Amélioration de la sélection du nombre de clés utilisées pour la recherche.

Version 3 : 1er août 2021

  • Ajoute un nouvel algorithme de jointure (jointure par fusion) activé à l'aide d'une nouvelle valeur d'optimisation de requête JOIN METHOD.

    Optimisation d'instruction :

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

    /*@ join_method=merge_join */
SELECT ...

    Optimisation de jointure :

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=merge_join} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=merge_join */ (...)

  • Ajoute un nouvel algorithme de jointure (jointure de hachage push) activé à l'aide d'une nouvelle valeur d'optimisation de requête JOIN METHOD.

    Optimisation de jointure :

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=push_broadcast_hash_join} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=push_broadcast_hash_join} */ (...)

  • Introduit l'opérateur d'union de fusion distribuée, qui est activé par défaut le cas échéant. Cette opération améliore les performances des requêtes.

  • Légère amélioration des performances d'une analyse sous un opérateur GROUP BY lorsqu'il n'y a pas d'agrégation MAX ou MIN (ou HAVING MAX/MAX) dans la liste SELECT. Avant cette modification, Spanner charge la colonne supplémentaire non regroupée même si elle n'est pas requise par la requête.

    Prenons comme exemple la table suivante :

    GoogleSQL 

    CREATE TABLE myTable(
  a INT64,
  b INT64,
  c INT64,
  d INT64)
PRIMARY KEY (a, b, c);

    PostgreSQL 

    CREATE TABLE myTable(
  a bigint,
  b bigint,
  c bigint,
  d bigint,
  PRIMARY KEY(a, b, c)
);

    Avant cette modification, la requête suivante aurait chargé la colonne c, même si elle n'est pas requise par la requête.

    SELECT a, b
FROM myTable
GROUP BY a, b

  • Améliore les performances de certaines requêtes avec LIMIT lorsqu'un opérateur d'application croisée est introduit par des jointures et que la requête demande des résultats triés avec LIMIT. Après cette modification, l'optimiseur applique d'abord le tri avec la limite du côté d'entrée de l'application croisée.

    Exemple :

    GoogleSQL 

    SELECT a2.*
FROM Albums@{FORCE_INDEX=_BASE_TABLE} a1
JOIN Albums@{FORCE_INDEX=_BASE_TABLE} a2 USING(SingerId)
ORDER BY a1.AlbumId
LIMIT 2;

    PostgreSQL 

    SELECT a2.*
FROM albums/*@ force_index=_base_table */ a1
JOIN albums/*@ force_index=_base_table */ a2 USING(singerid)
ORDER BY a1.albumid
LIMIT 2;

  • Améliore les performances des requêtes en envoyant davantage de calculs via JOIN.

    Transmet plus de calculs pouvant inclure une sous-requête ou une construction de structure via une jointure. Cela améliore les performances des requêtes de plusieurs manières : plus de calculs peuvent être effectués de manière distribuée et plus d'opérations dépendantes des calculs push peuvent être transférées. Par exemple, la requête a une limite et l'ordre de tri dépend de ces calculs. Dans ce cas, la limite peut également être transmise via une jointure.

    Exemple :

    SELECT
  t.ConcertDate,
  (
    SELECT COUNT(*) FROM UNNEST(t.TicketPrices) p WHERE p > 10
  ) AS expensive_tickets,
  u.VenueName
FROM Concerts t
JOIN Venues u ON t.VenueId = u.VenueId
ORDER BY expensive_tickets
LIMIT 2;

Version 2 : 1er mars 2020

  • Ajoute des optimisations dans la sélection d'index.
  • Améliore les performances des prédicats REGEXP_CONTAINS et LIKE dans certaines circonstances.
  • Améliore les performances d'une analyse sous un opérateur GROUP BY dans certains cas.

Version 1 : 18 juin 2019

  • Inclut de nombreuses optimisations basées sur des règles, telles que le pushdown de prédicat, le pushdown de limite, la jointure redondante et la suppression d'expressions redondantes.

  • Utilise les statistiques de données utilisateur pour sélectionner l'index à utiliser pour accéder à chaque table.

Étape suivante