Téléchargement du traqueur pour PostgreSQL 11, 12, 13, 14 et 15
Téléchargement du traqueur pour PostgreSQL 10
Téléchargement du traqueur pour PostgreSQL 9.6
Téléchargement du traqueur pour PostgreSQL 9.5
Téléchargement du traqueur pour PostgreSQL 9.4
Téléchargement du traqueur pour PostgreSQL 9.3
Journal des changements
Signalement de bugs via le forum
Licence identique à celle de PostgreSQL, open source type BSD
Dossier des versions
Dans une entreprise lointaine, vous êtes sollicité car une recherche paraissant simple donne une impression désagréable. Cela reste utilisable mais lutilisateur décrit un manque de réactivité, la résultat nest pas immédiat. Lapplication est compatible avec Oracle Database et PostgreSQL et le phénomène est commun aux 2 SGBD.Vous décidez de faire tourner le traqueur alors que lutilisateur effectue sa recherche :
Votre exécution du traqueur vous permet de détecter 2 requêtes. Elles se ressemblent beaucoup, la première consistant à compter le nombre de lignes que ramènera la seconde. Cest une première information à remonter aux développeurs. Ce genre de code est souvent utilisé pour prévenir les utilisateurs que leur recherche va ramener beaucoup de lignes. Cependant il y a des moyens plus efficaces de procéder avec UNE requête, quel que soit loutil de développement.
Cest une remarque générale mais cela nexplique pas le sentiment de lenteur confirmé par le traqueur. Vos 16 détections de chaque requête donne une idée approximative de leur durée. Chaque requête doit durer au moins 1s6, vous avez en effet laissé les paramètres par défaut pour la fréquence dinterrogation de pg_stat_activity qui a lieu chaque dixième de seconde.
Il est temps de sintéresser à la table t1, ses colonnes et son indexation :
La colonne c1 est de type character varying et constitue la clé primaire de t1. Une requête via la clé primaire devrait être très rapide mais la conversion vers un bigint effectuée sur la colonne c1 empêche lutilisation de lindex. Un balayage complet (seq scan) de t1 est réalisé, la requête dure ainsi 1622ms au lieu de moins de 2ms.
Sous Oracle, la conversion était implicite et le problème un peu plus difficile à cerner. Il aurait dû être résolu naturellement lors de ladaptation du code à PostgreSQL en utilisant une variable de type chaîne de caractère au lieu dune valeur numérique. Vous interrogez le développeur qui vous confirme quil a obtenu une erreur lors de la première exécution de la recherche sous PostgreSQL. Il a choisi la mauvaise solution pour résoudre le problème. Plutôt que de corriger le bug tout en améliorant les performances, il a appliqué la conversion sur la colonne au lieu de choisir le bon type pour le critère de recherche. Une petite modification du programme confirme le diagnostic, les performances sont améliorées à la fois sous Oracle et PostgreSQL. La recherche donne alors un résultat quasi immédiat, mission réussie.