Versiones del optimizador de consultas de Spanner

En esta página, se describen las distintas versiones del optimizador de consultas de Spanner y se proporciona un historial de ellas. La versión predeterminada actual es la 8. Para obtener más información sobre el optimizador de consultas, consulta la Descripción general 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 30 días después de que se lanza esa versión.

Puedes administrar la versión del optimizador de consultas que usan tus consultas para las bases de datos de dialecto de GoogleSQL y dialecto de PostgreSQL. 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 incluye un resumen de las actualizaciones realizadas en el optimizador de consultas en cada versión.

Versión 8: 28 de octubre de 2024 (predeterminada y más reciente)

  • Las cláusulas WITH se tienen en cuenta cuando se eligen planes basados en el costo.

  • Se mejoró el rendimiento de las consultas de búsqueda indexadas y de aplicación cruzada distribuida.

  • Se mejoró el reordenamiento de JOIN.

  • Se mejoró el rendimiento de las consultas con cláusulas IN (...) grandes.

  • Se mejoró el rendimiento de GROUP BY en ciertos casos.

  • Otras mejoras, como el manejo más eficiente de las consultas con LIMIT, claves externas y selección de índices

Versión 7: 22 de mayo de 2024

  • 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 planes de análisis según las estadísticas de las búsquedas que no tienen predicados aptos para la búsqueda en todas las partes clave.

  • Se agregó compatibilidad para la selección basada en costos de las uniones de hash.

Versión 6: 11 de septiembre de 2023

  • Se mejoró el envío de límites y predicados a través de combinaciones externas completas.

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

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

  • Se agregó compatibilidad con la selección de algoritmos de unión basada en costos que elige entre la unión de hash y la unión de aplicación. La combinación por fusió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

  • Se mejoró 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 indican que la tabla base es pequeña.

  • Se introduce la combinación hash de un solo paso, habilitada por la nueva sugerencia hash_join_execution.

    Sugerencia para unirse:

    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 nuevo modo es beneficioso cuando la entrada del lado de la compilación de la unión hash es grande. Se espera que la unión hash de un solo paso tenga un mejor rendimiento cuando observes lo siguiente en el perfil de ejecución de la consulta:

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

    De forma predeterminada (hash_join_execution=multi_pass), si la entrada secundaria de compilación de la combinación hash es demasiado grande para caber en la memoria, el lado de compilación se divide en varios lotes y es posible que exploremos el lado de sondeo varias veces. Con el nuevo modo (hash_join_execution=one_pass), una unión hash se volcará en el disco si su entrada del lado de la compilación no cabe en la memoria y siempre analizará el lado de la sonda solo una vez.

  • Se mejoró la selección de la cantidad de teclas que se usan para la búsqueda.

Versión 3: 1 de agosto de 2021

  • Se agregó un nuevo algoritmo de unión, la unión por combinació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 de unión:

    GoogleSQL 

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

    PostgreSQL 

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

  • Se agregó un nuevo algoritmo de unión, la unión hash de transmisión de inserción, que se habilita con un nuevo valor de sugerencia de consulta 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} */ (...)

  • Se introduce el operador unión de fusión distribuida, que está habilitado de forma predeterminada cuando corresponde. Esta operación mejora el rendimiento de las consultas.

  • Se produjo una pequeña mejora en el rendimiento de un análisis bajo 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 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 de este cambio, la siguiente consulta habría cargado la columna c, aunque no fuera 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 cross apply introducido por las uniones y la consulta solicita resultados ordenados con LIMIT. Después de este cambio, el optimizador aplica la ordenación con el límite en el lado de entrada de la aplicación cruzada primero.

    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 al enviar más cálculos 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 una unión. Esto mejora el rendimiento de las consultas de varias maneras, por ejemplo, se pueden realizar más cálculos de forma distribuida y también se pueden enviar más operaciones que dependen de los cálculos enviados. Por ejemplo, si 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

  • Se agregaron 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 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?