Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verbesserung der Aurora PostgreSQL-Abfragepläne

Verbessern Sie die Verwaltung von Abfrageplänen, indem Sie die Leistung des Plans bewerten und Pläne korrigieren. Weitere Informationen zur Verbesserung Ihrer Abfragepläne finden Sie in den folgenden Themen.

Auswerten der Performance von Plänen

Nachdem der Optimierer Pläne als „Nicht genehmigt“ erfasst hat, können Sie mit der Funktion apg_plan_mgmt.evolve_plan_baselines Pläne hinsichtlich ihrer tatsächlichen Performance miteinander vergleichen. Je nach Ergebnis dieses Performance-Vergleichs können Sie den Status eines Plans von „Nicht genehmigt“ zu „Genehmigt“ oder „Abgelehnt“ ändern. Alternativ besteht die Möglichkeit, mit der Funktion apg_plan_mgmt.evolve_plan_baselines einen Plan auf bestimmte Zeit zu deaktivieren, falls er Ihre Anforderungen nicht erfüllt.

Genehmigen besserer Pläne

Im folgenden Beispiel wird beschrieben, wie der Status verwalteter Pläne mit der Funktion apg_plan_mgmt.evolve_plan_baselines auf „Genehmigt“ geändert werden kann.

SELECT apg_plan_mgmt.evolve_plan_baselines (
   sql_hash, 
   plan_hash, 
   min_speedup_factor := 1.0, 
   action := 'approve'
) 
FROM apg_plan_mgmt.dba_plans WHERE status = 'Unapproved';

NOTICE:     rangequery (1,10000)
NOTICE:     Baseline   [ Planning time 0.761 ms, Execution time 13.261 ms]
NOTICE:     Baseline+1 [ Planning time 0.204 ms, Execution time 8.956 ms]
NOTICE:     Total time benefit: 4.862 ms, Execution time benefit: 4.305 ms
NOTICE:     Unapproved -> Approved
evolve_plan_baselines 
-----------------------
0
(1 row)     

In der Ausgabe wird ein Performance-Bericht für dierangequery-Anweisung mit Parameterbindungen von 1 und 10 000 angezeigt. Der neue nicht genehmigte Plan (Baseline+1) ist besser als der beste zuvor genehmigte Plan (Baseline). Rufen Sie die Approved-Ansicht auf, um zu sehen, ob der neue Plan nun den Status „apg_plan_mgmt.dba_plans“ aufweist.

SELECT sql_hash, plan_hash, status, enabled, stmt_name 
FROM apg_plan_mgmt.dba_plans;

sql_hash  | plan_hash |  status  | enabled | stmt_name  
------------+-----------+----------+---------+------------
1984047223 | 512153379 | Approved | t       | rangequery
1984047223 | 512284451 | Approved | t       | rangequery
(2 rows)

Der verwaltete Plan enthält jetzt zwei genehmigte Pläne, die zusammen die Plan-Baseline der Anweisung bilden. Sie können auch die Funktion „apg_plan_mgmt.set_plan_status“ aufrufen, um das Statusfeld eines Plans direkt auf 'Approved', 'Rejected', 'Unapproved' oder 'Preferred' festzulegen.

Ablehnen oder Deaktivieren langsamerer Pläne

Leiten Sie 'reject' oder 'disable' als Aktionsparameter an die Funktion apg_plan_mgmt.evolve_plan_baselines weiter, um Pläne abzulehnen oder zu deaktivieren. In diesem Beispiel wird jeder erfasste Plan mit dem Status „Unapproved“ deaktiviert, der um mindestens 10 Prozent langsamer als der beste Plan mit dem Status „Approved“ der Anweisung ist.

SELECT apg_plan_mgmt.evolve_plan_baselines(
sql_hash,  -- The managed statement ID
plan_hash, -- The plan ID
1.1,       -- number of times faster the plan must be 
'disable'  -- The action to take. This sets the enabled field to false.
)
FROM apg_plan_mgmt.dba_plans
WHERE status = 'Unapproved' AND   -- plan is Unapproved
origin = 'Automatic';       -- plan was auto-captured

Sie können den Status eines Plans auch direkt auf „Abgelehnt“ oder „Deaktiviert“ setzen. Rufen Sie die Funktion true auf, um das aktivierte Feld eines Plans direkt auf false oder apg_plan_mgmt.set_plan_enabled festzulegen. Mit der Funktion „'Approved'“ legen Sie das Statusfeld eines Plans direkt auf 'Rejected', 'Unapproved', 'Preferred' oder apg_plan_mgmt.set_plan_status fest.

Verwenden Sie die apg_plan_mgmt.validate_plans-Funktion, um Pläne zu löschen, die nicht gültig sind und voraussichtlich ungültig bleiben werden. Mit dieser Funktion können Sie ungültige Pläne löschen oder deaktivieren. Weitere Informationen finden Sie unter Validieren von Plänen.

Reparieren von Plänen mit pg_hint_plan

Mit dem Abfrageoptimierer kann für jede Anweisung der bestmögliche Plan gefunden werden. In den meisten Fällen findet der Abfrageoptimierer in der Tat einen guten Plan. Manchmal gibt es jedoch einen weitaus besseren als den vom Optimierer erstellten Plan. Um zu gewährleisten, dass der Optimierer einen passenden Plan erstellt, wird zum einen die Verwendung der Erweiterung pg_hint_plan, zum anderen die Festlegung der Grand Unified Configuration (GUC)-Variablen in PostgreSQL empfohlen:

Wenn Sie den Abfrageoptimierer mit einer dieser Methoden zur Verwendung eines Plans zwingen, können Sie auch die Abfrageplanverwaltung nutzen, um den neuen Plan zu erfassen und dessen Anwendung durchzusetzen.

Mit der Erweiterung pg_hint_plan können Sie die Join-Reihenfolge, die Join-Methoden oder die Zugriffspfade für eine SQL-Anweisung ändern. Sie nutzen einen SQL-Kommentar mit einer besonderen pg_hint_plan-Syntax, um die üblicherweise vom Optimierer angewendete Planerstellungsmethode zu ändern. Angenommen, die entsprechende SQL-Anweisung verfügt über eine Zwei-Wege-Verknüpfung.

SELECT * 
FROM t1, t2 
WHERE t1.id = t2.id;            

Der Optimierer wählt nun die Join-Reihenfolge (t1, t2) aus. Wir wissen jedoch, dass die Reihenfolge (t2, t1) schneller ist. Der folgende Hinweis zwingt den Optimierer dazu, die schnellere Join-Reihenfolge (t2, t1) zu wählen. Schließen Sie EXPLAIN ein, damit der Optimierer einen Plan für die SQL-Anweisung generiert, ohne jedoch die Anweisung auszuführen. (Ausgabe wird nicht angezeigt.)

/*+ Leading ((t2 t1)) */ EXPLAIN SELECT * 
FROM t1, t2 
WHERE t1.id = t2.id; 

Im Folgenden wird beschrieben, wie Sie verwende pg_hint_plan.