Versiones del optimizador de consultas de Spanner

En esta página, se describen y proporcionan un historial de las diversas 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 versión más reciente del optimizador no antes de los 30 días posteriores al lanzamiento de esa versión.

Si usas una base de datos con dialectos de GoogleSQL, puedes administrar la versión del optimizador de consultas que utilizan tus consultas. Antes de confirmar la última versión, puedes comparar los perfiles de rendimiento de las consultas entre 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

El siguiente es un resumen de las actualizaciones realizadas al optimizador de consultas en cada versión.

Versión 6: 11 de septiembre de 2023 (más reciente y predeterminada)

  • Se mejoró 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 los costos para las 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 distribución, la posición de orden 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 aplicación de unión. La combinación de combinaciones aún requiere el uso de una sugerencia de consulta.

  • Se agregó compatibilidad para la conmutación de unión basada en costos.

Versión 4: 1 de marzo de 2022

  • Mejoras en la selección de índice secundario

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

  • Introduce 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 la unión de hash es grande. Se espera que una unión de hash de pase tenga un mejor rendimiento cuando observes lo siguiente en el perfil de ejecución de consultas:

    • La cantidad de ejecuciones del elemento secundario derecho de la unión de hash es mayor que la cantidad de ejecuciones en el operador de unión de 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 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 lado del sondeo varias veces. Con el modo nuevo (hash_join_execution=one_pass), una unión hash se volcará 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 utilizan para buscar.

Versión 3: 1 de agosto de 2021

  • Agrega un nuevo algoritmo de unión, combinación de combinación, habilitada mediante 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, la unión de hash de transmisión de envío, y se habilita mediante un nuevo valor de sugerencia de consulta 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 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 un agregado MAX o MIN (o HAVING MAX/MAX) en la lista SELECT. Antes del cambio, Spanner cargaba la columna adicional no agrupada, incluso si la consulta no la requería.

    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 del cambio, la siguiente consulta habrí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 uniones y la consulta solicita resultados ordenados con LIMIT. Después de este cambio, el optimizador aplica primero el orden 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, ya que envía más procesamientos a través de JOIN.

    Envía más cálculos, que pueden incluir una subconsulta o la construcción de una estructura a través de la unión. Eso mejora el rendimiento de las consultas de varias maneras, como las siguientes: se pueden realizar más cálculos de forma distribuida y también se pueden mover 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; 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 ciertas circunstancias.
  • Mejora el rendimiento de un análisis en un GROUP BY en determinadas 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?