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 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 una consulta nueva del optimizador. De forma predeterminada, cada base de datos comienza a usar la última versión de el 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 comprometerte con la versión más reciente, puedes comparar para consultar perfiles de rendimiento entre 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 presenta un resumen de las actualizaciones realizadas en el optimizador de consultas en cada lanzamiento.

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 con la selección inteligente de planes de búsqueda y análisis basados en estadísticas de las consultas que no tienen predicados que se pueden buscar 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

  • Modelo de costos mejorado para la selección de índices, la administración de la distribución y la ordenación posición y la selección de GROUP BY.

  • Se agregó compatibilidad con la selección del algoritmo de unión basada en el costo que elige entre generar un hash y aplicar unió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 informa la tabla base es pequeño.

  • 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 hash de pase tenga un mejor rendimiento cuando Observa 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 varios 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 unión, unión de combinación, habilitado con un nuevo MÉTODO DE UNIÓN el valor de la sugerencia de la consulta.

    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 hash de transmisión push, habilitada con 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 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 por debajo de 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 los datos incluso si la consulta no lo había requerido.

    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 una el operador de aplicación cruzada ingresado por las uniones y la consulta solicita ordenar resultados con LIMIT. Después de este cambio, el optimizador aplica el orden con el límite del 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 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 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 estadísticas sobre los datos del usuario a fin de seleccionar qué índice usar para acceder a cada uno desde una tabla de particiones.

¿Qué sigue?