En esta página, se documenta el conocimiento de la caché durante los análisis de indexación. Cuando se habilita, el optimizador de consultas de AlloyDB para PostgreSQL ajusta el costo de E/S estimado de los análisis de índice según la cantidad de páginas de índice y de tabla que ya están disponibles en el búfer compartido cuando comienza la ejecución. Luego, se selecciona el plan de consulta final según los costos ajustados del plan. Esto mejora el rendimiento de las consultas y reduce los costos de la base de datos.
Una vez habilitada, la función de reconocimiento de caché funciona automáticamente y se ajusta al estado cambiante de la llegada al búfer compartido. Además, el conocimiento de la caché puede funcionar junto con otras prácticas de ajuste de consultas, como establecer la estimación de costos del optimizador de consultas de AlloyDB en random_page_cost.
Habilita la detección de caché
Para habilitar el reconocimiento de caché en tu instancia de AlloyDB, establece la marca alloydb.enable_cache_aware_costing (versión preliminar) en on. También puedes establecer la marca a nivel de la sesión para que afecte los planes de consulta que se producen en la misma sesión. Para obtener información sobre cómo configurar la marca, consulta Configura las marcas de base de datos de una instancia.
Situación de ejemplo
En el siguiente muestra de código, se muestra un plan de análisis de índice ejecutado con una caché de búfer compartida completamente activa.
explain (analyze, verbose, buffers)
SELECT count(d) FROM t1 WHERE a = 10 AND b > 100 AND c > 100;
------------------ Aggregate (cost=3908.93..3908.94 rows=1 width=8) (actual time=4.128..4.130 rows=1 loops=1)
Output: count(d)
Buffers: shared hit=926
-> Index Scan using idx1 on public.t1 (cost=0.43..3906.49 rows=975 width=2) (actual time=0.143..3.205 rows=919 loops=1)
Output: a, b, c, d
Index Cond: ((t1.a = 10) AND (t1.b > 100) AND (t1.c > 100))
Buffers: shared hit=926
Execution Time: 4.353 ms
Durante esta ejecución, no hubo lecturas de E/S. Sin la detección de caché, el optimizador de consultas incluye el costo de E/S para el plan de consultas de análisis del índice. Esto puede hacer que el plan de consultas de análisis del índice pierda ante un plan de consultas de análisis secuencial.
El siguiente fragmento de código muestra el costo ajustado del plan de consulta cuando la función de reconocimiento de caché está habilitada.
explain (verbose)
SELECT count(d) FROM t1 WHERE a = 10 AND b > 100 AND c > 100;
------------------ Aggregate (cost=29.93..29.94 rows=1 width=8)
Output: count(d)
-> Index Scan using idx1 on public.t1 (cost=0.43..27.49 rows=975 width=2)
Output: a, b, c, d
Index Cond: ((t1.a = 10) AND (t1.b > 100) AND (t1.c > 100))
El costo nuevo, 27.49, para el mismo plan de consulta de análisis de índice es mucho más bajo que el costo anterior, 3906.49.