Versiones del optimizador de consultas de Spanner

En esta página, se describe y se proporciona un historial de las diferentes versiones del optimizador de consultas de Spanner. La versión predeterminada actual es 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 versiones nuevas del optimizador de consultas. De forma predeterminada, cada base de datos comienza a usar la última versión del optimizador no antes de los 30 días posteriores al lanzamiento de esa versión.

Si usas una base de datos de dialectos 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 obtener más información, consulta Administra el optimizador de consultas.

Historial de versiones del optimizador de consultas

A continuación, se presenta 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 para la selección basada en costos de planes de unión de índices.

  • Se agregó compatibilidad para la selección inteligente de planes de búsqueda frente a análisis basados en estadísticas de consultas que no tienen predicados que pueden buscarse para todas las partes clave.

  • Se agregó compatibilidad para la selección basada en costos de uniones 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.

  • Estimación de cardinalidad y modelo de costos mejorados

  • Se habilitó la optimización basada en costos para consultas 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 la distribución, la posición de ordenamiento y la selección de GROUP BY.

  • Se agregó compatibilidad para la selección del algoritmo de unión basada en costos que elige entre hash y 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 uniones basadas en costos.

Versión 4: 1 de marzo de 2022

  • Mejoras en la selección de índices secundarios

    • Se mejoró el uso de índices secundarios en una unión entre tablas intercaladas.
    • Se mejoró la cobertura del uso de índices secundarios.
    • Se mejora la selección de índices cuando las estadísticas del optimizador están desactualizadas.
    • Opta por índices secundarios con predicados en las principales columnas indexadas, incluso si las estadísticas del optimizador no están disponibles o si 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 una unión de hash de pase tenga un mejor rendimiento cuando observas 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 de la compilación de la unión hash es demasiado grande para caber en la memoria, la compilación se divide en varios lotes y es posible que analicemos el sondeo varias veces. Con el modo nuevo (hash_join_execution=one_pass), una unión hash se derramará al disco si su entrada complementaria de compilación no puede caber en la memoria y siempre analizará el lado del sondeo solo una 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 unión, combinación de combinación, habilitado mediante un nuevo valor de sugerencia de consulta de JOIN METHOD.

    Sugerencia de sentencia:

    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 de hash de transmisión push, habilitada mediante un nuevo valor de sugerencia de consulta de JOIN METHOD.

    Sugerencia para unirse:

    GoogleSQL 

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

    PostgreSQL 

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

  • Presenta el operador de unión de combinación distribuida, que está habilitado 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 un agregado MAX o MIN (o HAVING MAX/MAX) en la lista SELECT. Antes de este cambio, Spanner cargaba la columna adicional no agrupada, incluso si la consulta no la necesitaba.

    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, 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 ingresado por las uniones y la consulta solicita resultados ordenados con LIMIT. Después de este cambio, el optimizador aplica primero el ordenamiento con el límite del 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 estructura a través de la unión. Esto mejora el rendimiento de las consultas de las siguientes maneras: se pueden realizar más cálculos de manera distribuida y también se pueden enviar hacia abajo más operaciones que dependen de los cálculos enviados. Por ejemplo, la consulta tiene un límite y el orden de clasificación depende de esos cálculos; entonces, el límite también se puede extender 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 estadísticas sobre los datos del usuario a fin de seleccionar qué índice usar para acceder a cada tabla.

¿Qué sigue?