Versiones del optimizador de consultas de Spanner

En esta página, se describe y se proporciona un historial de las diversas consultas de Spanner. del optimizador. La versión predeterminada actual es la 6. Para obtener más información sobre el optimizador de consultas, consulta Acerca del optimizador de consultas.

Spanner lanza actualizaciones del optimizador de consultas como nuevas versiones del optimizador. De forma predeterminada, cada base de datos comienza a usar la versión más reciente del optimizador, al menos, 30 días después de que se publica.

Si usas una base de datos de dialecto de GoogleSQL, puedes administrar la versión del optimizador de consultas que usan tus consultas. Antes de confirmar la versión más reciente, puedes comparar los perfiles de rendimiento de las consultas entre las versiones anteriores y la más reciente. Para Para obtener más información, consulta Administra el optimizador de consultas.

Historial de versiones del optimizador de consultas

A continuación, se muestra un resumen de las actualizaciones realizadas en el optimizador de consultas en cada versión.

Versión 7: 22 de mayo de 2024 (más reciente)

  • Se agregó compatibilidad con la selección basada en el costo de los planes de unión de índices.

  • Se agregó compatibilidad con la selección inteligente de planes de búsqueda en comparación con los de análisis según las estadísticas de las consultas que no tienen predicados que se pueden buscar para todas las partes clave.

  • Se agregó compatibilidad con la selección basada en el costo de las uniones de hash.

Versión 6: 11 de septiembre de 2023 (predeterminada)

  • Mejoras en el envío de límites y el envío de predicados a través de uniones externas completas.

  • Se mejoró la estimación de cardinalidad y el modelo de costos.

  • Se habilitó la optimización basada en el costo para las consultas de DML.

Versión 5: 15 de julio de 2022

  • Se mejoró el modelo de costos para la selección de índices, la administración de distribución, la ubicación de ordenamiento y la selección de GROUP BY.

  • Se agregó compatibilidad con la selección de algoritmo de unión basada en el costo que elige entre la unión de hash y la unión de aplicación. La combinación de combinación aún requiere el uso de una sugerencia de consulta.

  • Se agregó compatibilidad con la conmutatividad de la unión basada en el costo.

Versión 4: 1 de marzo de 2022

  • Mejoras en la selección de índices secundarios

    • Se mejoró el uso del índice secundario en una unión entre tablas intercaladas.
    • Se mejoró el uso del índice secundario de cobertura.
    • Se mejoró la selección de índices cuando las estadísticas del optimizador están desactualizadas.
    • Prefiere los índices secundarios con predicados en las columnas indexadas principales, incluso si las estadísticas del optimizador no están disponibles o si se informa que la tabla base es pequeña.

  • Presenta la unión hash de un solo pase, habilitada por la nueva sugerencia hash_join_execution

    Sugerencia de unión:

    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 */ (...)

    El modo nuevo es beneficioso cuando la entrada complementaria de compilación de la unión hash. es grande. Se espera que la unión hash de un solo pase tenga un mejor rendimiento cuando observes lo siguiente en el perfil de ejecución de consultas:

    • La cantidad de ejecuciones en el elemento secundario derecho de la unión hash es mayor que la cantidad de ejecuciones del operador de unión hash.
    • La latencia en el elemento secundario derecho del operador de unión hash también es alta.

    De forma predeterminada (hash_join_execution=multi_pass), si la entrada complementaria de compilación de la unión hash es demasiado grande para caber en la memoria, el lado de la compilación se divide en en múltiples lotes, y es posible que analicemos el lado del sondeo varias veces. Con la modo nuevo (hash_join_execution=one_pass), una unión hash se derramará al disco si su entrada complementaria de compilación no cabe en la memoria y siempre analizará el sondeo una sola vez.

  • Una mejora en la selección de cuántas teclas se usan para buscar.

Versión 3: 1 de agosto de 2021

  • Agrega un nuevo algoritmo de combinación, la combinación de unión, que se habilita con un nuevo valor de sugerencia de consulta JOIN METHOD.

    Sugerencia de instrucción:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

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

    Sugerencia para unirse:

    GoogleSQL 

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

    PostgreSQL 

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

  • Agrega un nuevo algoritmo de unión, unión hash de transmisión push, habilitada con un nuevo Valor de sugerencia de consulta de JOIN METHOD.

    Sugerencia de unión:

    GoogleSQL 

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

    PostgreSQL 

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

  • Presenta la unión de combinación distribuida. que se habilita de forma predeterminada cuando corresponde. Esta operación mejora el rendimiento de las consultas.

  • Una pequeña mejora en el rendimiento de un análisis en un GROUP BY cuando no hay una agregación MAX o MIN (o HAVING MAX/MAX) en la lista SELECT. Antes de este cambio, Spanner cargaba los datos aunque esto no fuera necesario para la consulta.

    Por ejemplo, considera la siguiente tabla:

    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)
);

    Antes de este cambio, la siguiente consulta había cargado la columna c incluso aunque no es necesaria para la consulta.

    SELECT a, b
FROM myTable
GROUP BY a, b

  • Mejora el rendimiento de algunas consultas con LIMIT cuando hay un operador de aplicación cruzada que introducen las uniones y la consulta solicita resultados ordenados con LIMIT. Después de este cambio, el optimizador aplica primero la ordenación con el límite en el lado de entrada de la aplicación cruzada.

    Ejemplo:

    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;

  • Mejora el rendimiento de las consultas mediante el envío de más procesamientos a través de JOIN.

    Envía más cálculos que pueden incluir una subconsulta o una construcción de struct a través de la unión. Eso mejora el rendimiento de las consultas de las siguientes maneras: Se pueden realizar más cálculos de forma distribuida y se pueden realizar más operaciones que dependen de los cálculos enviados también se pueden impulsar. Para ejemplo, la consulta tiene un límite y el orden de clasificación depende de esos de procesamiento, el límite también se puede enviar a través de la unión.

    Ejemplo:

    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;

Versión 2: 1 de marzo de 2020

  • Agrega optimizaciones en la selección de índices.
  • Mejora el rendimiento de los predicados REGEXP_CONTAINS y LIKE en determinadas circunstancias.
  • Mejora el rendimiento de un análisis en un GROUP BY en ciertas situaciones.

Versión 1: 18 de junio de 2019

  • Incluye muchas optimizaciones basadas en reglas, como el pushdown del predicado, el límite de pushdown, la unión redundante y la eliminación de expresiones redundantes, por nombrar algunas.

  • Usa las estadísticas de los datos del usuario para seleccionar el índice que se usará para acceder a cada tabla.

¿Qué sigue?