Auf dieser Seite wird beschrieben, wie der Cache bei Indexscans berücksichtigt wird. Wenn diese Option aktiviert ist, passt der AlloyDB for PostgreSQL-Abfrageplaner die geschätzten E/A-Kosten von Indexscans basierend darauf an, wie viele Index- und Tabellenseiten zu Beginn der Ausführung bereits im freigegebenen Puffer verfügbar sind. Der endgültige Abfrageplan wird dann auf Grundlage der angepassten Plankosten ausgewählt. Dadurch wird die Abfrageleistung verbessert und die Datenbankkosten werden gesenkt.
Nach der Aktivierung funktioniert die Cache-Awareness-Funktion automatisch und passt sich an den sich ändernden Status des gemeinsamen Puffers an. Außerdem kann die Cache-Berücksichtigung mit anderen Methoden zur Optimierung von Abfragen kombiniert werden, z. B. mit der Einstellung der Kostenschätzung des AlloyDB-Abfrageplaners auf random_page_cost.
Cache-Awareness aktivieren
Wenn Sie die Cache-Unterstützung für Ihre AlloyDB-Instanz aktivieren möchten, legen Sie das Flag alloydb.enable_cache_aware_costing (Vorabversion) auf on fest. Sie können das Flag auch auf Sitzungsebene festlegen, um die Abfragepläne zu beeinflussen, die in derselben Sitzung ausgeführt werden. 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 gemeinsamen Puffer-Cache 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 Lese-E/A-Vorgänge. Ohne Cache-Bewusstsein 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 dem Abfrageplan für den sequenziellen Scan verliert.
Das folgende Code-Snippet zeigt die angepassten Kosten des Abfrageplans, 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.