En esta página se describe cómo se gestiona la caché durante los análisis de índices. Cuando está habilitado, el planificador de consultas de AlloyDB para PostgreSQL ajusta el coste de E/S estimado de los análisis de índices en función de cuántas páginas de índice y de tabla ya están disponibles en el búfer compartido cuando se inicia la ejecución. A continuación, se selecciona el plan de consulta final en función de los costes ajustados del plan. De esta forma, se mejora el rendimiento de las consultas y se reducen los costes de las bases de datos.
Una vez habilitada, la función de detección de caché funciona automáticamente y se ajusta al cambio de estado de acceso al búfer compartido. Además, la conciencia de la caché puede combinarse con otras prácticas de ajuste de consultas, como definir la estimación de costes del planificador de consultas de AlloyDB en random_page_cost.
Habilitar la compatibilidad con la caché
Para habilitar la compatibilidad con la caché en tu instancia de AlloyDB, asigna el valor on a la marca alloydb.enable_cache_aware_costing
(Vista previa). También puede definir la marca a nivel de sesión para que afecte a los planes de consulta que se produzcan en la misma sesión. Para obtener información sobre cómo definir la marca, consulta el artículo Configurar las marcas de la base de datos de una instancia.
Caso de ejemplo
En el siguiente código de ejemplo se muestra un plan de análisis de índice ejecutado con una caché de búfer compartida totalmente calentada.
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 se han realizado lecturas de E/S. Sin tener en cuenta la caché, el planificador de consultas incluye el coste de E/S del plan de consulta de análisis de índice. Esto puede provocar que el plan de consulta de análisis de índice pierda frente a un plan de consulta de análisis secuencial.
El siguiente fragmento de código muestra el coste ajustado del plan de consulta cuando se habilita la detección de caché.
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 nuevo coste, 27.49, del mismo plan de consulta de análisis de índice es mucho menor que el coste antiguo, 3906.49.