Pour améliorer les performances des requêtes et réduire les coûts d'E/S de la base de données, vous pouvez activer l'évaluation des coûts d'analyse d'index basée sur le cache dans AlloyDB pour PostgreSQL. Lorsque vous activez l'estimation des coûts d'analyse d'index basée sur le cache, le planificateur de requêtes AlloyDB ajuste le coût d'E/S estimé des analyses d'index en fonction du nombre de pages d'index et de table disponibles dans le tampon partagé au début de l'exécution, puis sélectionne le plan de requête final en fonction de ces coûts ajustés.
Une fois que vous avez activé la reconnaissance du cache, la fonctionnalité s'exécute automatiquement et s'ajuste lorsque les taux d'accès au tampon partagé changent. La reconnaissance du cache peut également fonctionner avec d'autres pratiques de réglage des requêtes, telles que la définition de l'estimation des coûts du planificateur de requêtes AlloyDB dans random_page_cost.
Activer la reconnaissance du cache
Pour activer la reconnaissance du cache pour votre instance AlloyDB, définissez le flag alloydb.enable_cache_aware_costing (preview) sur on. Vous pouvez également définir l'option au niveau de la session pour affecter les plans de requête qui se produisent au cours de la même session. Pour savoir comment définir l'indicateur de base de données, consultez Configurer les indicateurs de base de données d'une instance.
Exemple de scénario
L'exemple de code suivant montre un plan d'analyse d'index exécuté avec un cache de tampon partagé entièrement préchauffé.
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
Pendant cette exécution, aucune lecture d'E/S n'a été effectuée. Sans la reconnaissance du cache, l'outil de planification des requêtes inclut le coût d'E/S pour le plan de requête d'analyse d'index. Le plan de requête d'analyse d'index peut alors être moins efficace qu'un plan de requête d'analyse séquentielle.
L'extrait de code suivant montre le coût ajusté du plan de requête lorsque la reconnaissance du cache est activée.
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))
Le nouveau coût, 27.49, pour le même plan de requête d'analyse d'index est bien inférieur à l'ancien coût, 3906.49.