Versions de l'optimiseur de requêtes Spanner

Cette page décrit et fournit un historique des différentes versions de l'optimiseur de requêtes Spanner. La version par défaut actuelle est 6. Pour en savoir plus sur l'optimiseur de requêtes, consultez la page À propos 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 moins 30 jours après la publication de cette version.

Si vous utilisez une base de données de dialecte GoogleSQL, vous pouvez gérer la version de l'optimiseur de requêtes utilisée par vos requêtes. Avant de passer à la dernière version, vous pouvez comparer les profils de performances des requêtes entre l'ancienne et la dernière version. Pour en savoir plus, consultez 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 6: 11 septembre 2023 (dernière version et par défaut)

  • Amélioration de la transmission des limites et du prédicat poussant via des jointures externes complètes.

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

  • 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 des index, la gestion de la distribution, le tri des emplacements et la sélection des GROUP BY.

  • Ajout de la prise en charge de l'algorithme de jointure basé sur le coût, qui choisit entre hachage et jointure par application. La jointure de fusion nécessite toujours l'utilisation d'un indice de requête.

  • Ajout de la prise en charge de la commutativité des jointures basées sur le coût.

Version 4: 1er mars 2022

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

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

  • Introduit une jointure de hachage en un seul passage, activée par la nouvelle suggestion hash_join_execution.

    Astuce pour participer:

    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 utile lorsque l'entrée secondaire de compilation de la jointure de hachage est volumineuse. La jointure de hachage en une passe devrait offrir de meilleures performances 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 droit de la jointure de hachage est supérieur au nombre d'exécutions pour l'opérateur de jointure de hachage.
    • La latence pour l'enfant droit de l'opérateur hash join est également élevée.

    Par défaut (hash_join_execution=multi_pass), si l'entrée côté compilation de la jointure de hachage est trop volumineuse pour tenir en mémoire, le côté build 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 se propage sur le disque si son entrée côté compilation ne peut pas tenir en mémoire et n'analyse toujours le côté de la vérification qu'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.

    Indice:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

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

    Indice:

    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.

    Indice:

    GoogleSQL 

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

    PostgreSQL 

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

  • Introduit l'opérateur distributed merge union (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 chargeait la colonne supplémentaire non groupée, même si elle n'était pas requise par la requête.

    Prenons l'exemple du tableau suivant:

    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 cross apply introduit par les 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é 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, par exemple : davantage de calculs peuvent être effectués de manière distribuée, et davantage d'opérations qui dépendent des calculs envoyés peuvent être supprimés. Par exemple, si la requête a une limite et que l'ordre de tri dépend de ces calculs, la limite peut également être poussée 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 prédicat 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 sur les données utilisateur pour sélectionner l'index à utiliser pour accéder à chaque table.

Étapes suivantes