Cette page décrit la prise en compte du cache lors des analyses d'index. Lorsqu'il est activé, le planificateur de requêtes AlloyDB pour PostgreSQL ajuste le coût d'E/S estimé des analyses d'index en fonction du nombre de pages d'index et de tables déjà disponibles dans le tampon partagé au début de l'exécution. Le plan de requête final est ensuite sélectionné en fonction des coûts ajustés du plan. Cela améliore les performances des requêtes et réduit les coûts de la base de données.
Une fois activée, la fonctionnalité de prise en compte du cache fonctionne automatiquement et s'adapte à l'évolution de l'état de l'accès au tampon partagé. De plus, la prise en compte du cache peut fonctionner avec d'autres pratiques d'optimisation des requêtes, comme la définition de l'estimation du coût du planificateur de requêtes AlloyDB sur random_page_cost.
Activer la prise en compte du cache
Pour activer la prise en compte du cache pour votre instance AlloyDB, définissez le flag alloydb.enable_cache_aware_costing (Aperçu) sur on. Vous pouvez également définir l'indicateur 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'option, consultez Configurer les options 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 mémoire 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
Aucune lecture d'E/S n'a été effectuée lors de cette exécution. Sans prise en compte du cache, le planificateur de requêtes inclut le coût des E/S pour le plan de requête d'analyse d'index. Cela peut entraîner la perte du plan de requête index scan au profit d'un plan de requête sequential scan.
L'extrait de code suivant montre le coût ajusté du plan de requête lorsque la prise en compte 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 beaucoup plus faible que l'ancien coût, 3906.49.