Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Améliorer les plans de SQL requêtes Aurora Postgre

Améliorez la gestion des plans de requêtes en évaluant les performances des plans et en corrigeant les plans. Pour plus d'informations sur l'amélioration de vos plans de requêtes, consultez les rubriques suivantes.

Évaluation des performances des plans

Une fois que l'optimiseur a capturé des plans en tant que non approuvés, utilisez la fonction apg_plan_mgmt.evolve_plan_baselines pour comparer les plans sur la base de leurs performances réelles. En fonction des résultats de vos analyses des performances, vous pouvez modifier le statut d'un plan de non approuvé en approuvé ou rejeté. Vous pouvez également décider d'utiliser la fonction apg_plan_mgmt.evolve_plan_baselines pour désactiver temporairement un plan s'il ne répond pas à vos exigences.

Approbation de plans plus performants

L'exemple suivant montre comment modifier le statut de plans gérés en approuvé à l'aide de la fonction apg_plan_mgmt.evolve_plan_baselines.

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)     

La sortie montre un rapport de performances pour l'instruction rangequery avec des liaisons de paramètres de 1 et 10 000. Le nouveau plan non approuvé (Baseline+1) est plus performant que le meilleur plan précédent approuvé (Baseline). Pour confirmer que le nouveau plan est désormais Approved, vérifiez la vue apg_plan_mgmt.dba_plans.

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)

Le plan géré inclut désormais deux plans approuvés, qui constituent la référence de plans de l'instruction. Vous pouvez également appeler la fonction apg_plan_mgmt.set_plan_status afin de définir directement le champ de statut d'un plan sur 'Approved', 'Rejected', 'Unapproved' ou 'Preferred'.

Rejet ou désactivation de plans plus lents

Pour rejeter ou désactiver des plans, transférez 'reject' ou 'disable' en tant que paramètre d'action à la fonction apg_plan_mgmt.evolve_plan_baselines. Cet exemple désactive tout plan Unapproved capturé qui est plus lent d'au moins 10 % que le meilleur plan Approved pour l'instruction.

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

Vous pouvez également définir directement un plan sur rejeté ou désactivé. Pour définir directement le champ activé du plan sur true ou false, appelez la fonction apg_plan_mgmt.set_plan_enabled. Pour définir directement le champ de statut d'un plan sur 'Approved', 'Rejected', 'Unapproved' ou 'Preferred', appelez la fonction apg_plan_mgmt.set_plan_status.

Pour supprimer des plans qui ne sont pas valides et dont vous pensez qu'ils le resteront, utilisez la fonction apg_plan_mgmt.validate_plans. Cette fonction vous permet de supprimer ou de désactiver des plans non valides. Pour de plus amples informations, veuillez consulter Validation des plans.

Correction de plans à l'aide de pg_hint_plan

L'optimiseur de requêtes est conçu pour rechercher un plan optimal pour toutes les instructions et, dans la plupart des cas, il trouve un très bon plan. Il peut toutefois arriver que vous sachiez qu'un plan plus performant que celui généré par l'optimiseur existe. Deux méthodes recommandées pour que l'optimiseur génère le plan souhaité incluent l'utilisation de l'pg_hint_planextension ou la définition de variables Grand Unified Configuration (GUC) dans SQL Postgre :

Lorsque vous utilisez une de ces techniques pour forcer l'optimiseur de requêtes à utiliser un plan, vous pouvez également utiliser la gestion des plans de requêtes pour capturer et imposer l'utilisation du nouveau plan.

Vous pouvez utiliser l'pg_hint_planextension pour modifier l'ordre de jointure, les méthodes de jointure ou les chemins d'accès pour une SQL instruction. Vous utilisez un SQL commentaire avec une pg_hint_plan syntaxe spéciale pour modifier la façon dont l'optimiseur crée un plan. Supposons, par exemple, que l'SQLénoncé du problème comporte une jointure bidirectionnelle.

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

Supposons ensuite que l'optimiseur choisisse d'utiliser l'ordre des jointures (t1, t2), alors que nous savons que l'ordre (t2, t1) est plus rapide. L'indicateur suivant oblige l'optimiseur à utiliser l'ordre des jointures plus rapide (t2, t1). Incluez EXPLAIN afin que l'optimiseur génère un plan pour l'SQLinstruction mais sans exécuter l'instruction. (Sortie non illustrée.)

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

Les étapes suivantes montrent comment utiliser pg_hint_plan.