Wenn Sie die Abfrageleistung verbessern und die E/A-Kosten für die Datenbank senken möchten, können Sie in AlloyDB for PostgreSQL die Kostenberechnung für cache-sensitive Indexscans aktivieren. Wenn Sie die Kostenberechnung für cache-orientierte Indexscans aktivieren, passt der AlloyDB-Abfrageplaner die geschätzten E/A-Kosten von Indexscans basierend auf der Anzahl der Index- und Tabellenseiten an, die beim Start der Ausführung im gemeinsamen Zwischenspeicher verfügbar sind. Der endgültige Abfrageplan wird dann basierend auf diesen angepassten Kosten ausgewählt.
Nachdem Sie die Cache-Erkennung aktiviert haben, funktioniert die Funktion automatisch und passt sich an, wenn sich die Trefferraten des gemeinsamen Zwischenspeichers ändern. Die Cache-Erkennung kann auch mit anderen Methoden zur Abfrageoptimierung verwendet werden, z. B. mit der Einstellung der Kostenschätzung für den AlloyDB-Abfrageplaner in random_page_cost.
Cache-Awareness aktivieren
Wenn Sie die Cache-Erkennung für Ihre AlloyDB-Instanz aktivieren möchten, setzen Sie das Flag alloydb.enable_cache_aware_costing (Vorabversion) auf on. Sie können das Flag auch auf Sitzungsebene festlegen, um die Abfragepläne zu beeinflussen, die in derselben Sitzung auftreten. Informationen zum Festlegen des Flags finden Sie unter Datenbank-Flags einer Instanz konfigurieren.
Beispielszenario
Das folgende Codebeispiel zeigt einen Indexscanplan, der mit einem vollständig aufgewärmten Cache für gemeinsame Zwischenspeicher ausgeführt wird.
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
Während dieser Ausführung gab es keine E/A-Lesevorgänge. Ohne Cache-Awareness berücksichtigt der Abfrageplaner die E/A-Kosten für den Indexscan-Abfrageplan. Dies kann dazu führen, dass der Abfrageplan für den Indexscan gegenüber einem Abfrageplan für den sequenziellen Scan verliert.
Das folgende Code-Snippet zeigt die angepassten Kosten für den Abfrageplan, wenn die Cache-Berücksichtigung aktiviert ist.
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))
Die neuen Kosten (27.49) für denselben Indexscan-Abfrageplan sind viel niedriger als die alten Kosten (3906.49).