Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 18/08/2016 12:25:33
- olivier.bouiron
- Membre
PgAdmin et Postgres 9.6 vs 9.3
Bonjour,
Notre base de prod étant en 9.3, nous planifions une mise à jour en fin d'année vers la 9.6 si la roadmap est tenue...
On a donc préparé un serveur de tests en 9.6: les conditions sont similaires au niveau du postgresql.conf, les deux serveurs sont sous debian (mais versions de debian différentes).
Par contre grosse différence: la 9.6 tourne sur des disques 7k tours en raid 5 alors que la 9.3 est sur du ssd.
J’exécute une même requête:
select * from premio_presc_v2 a inner join dsi_presc_cycle b on a.id=b.idpres inner join premio_presc_jour_produit c on c.idcycle=b.id where a.nip=200903667 and b.cycle=2 limit 10;
Sous 9.6 ça prends 13ms pour afficher le resultat dans pg_admin
Sous 9.3 ça prends 22ms pour afficher le resultat dans pg_admin
Le explain analyze en 9.6 donne:
Limit (cost=1.14..18.45 rows=5 width=1439) (actual time=0.059..0.085 rows=10 loops=1)
-> Nested Loop (cost=1.14..18.45 rows=5 width=1439) (actual time=0.057..0.083 rows=10 loops=1)
-> Nested Loop (cost=0.71..13.53 rows=1 width=986) (actual time=0.042..0.042 rows=1 loops=1)
-> Index Scan using idx_presc_premio_nip on premio_presc_v2 a (cost=0.29..5.41 rows=2 width=577) (actual time=0.017..0.017 rows=1 loops=1)
Index Cond: (nip = 200903667)
-> Index Scan using idx_dsi_cycle on dsi_presc_cycle b (cost=0.42..4.05 rows=1 width=409) (actual time=0.019..0.019 rows=1 loops=1)
Index Cond: (idpres = a.id)
Filter: (cycle = 2)
Rows Removed by Filter: 2
-> Index Scan using idx_presc_jour_premio1 on premio_presc_jour_produit c (cost=0.43..4.58 rows=34 width=453) (actual time=0.011..0.022 rows=10 loops=1)
Index Cond: (idcycle = b.id)
Planning time: 1.645 ms
Execution time: 0.480 ms
et le explain analyze en 9.3 donne:
Limit (cost=1.14..13.53 rows=5 width=1447) (actual time=0.040..0.055 rows=10 loops=1)
-> Nested Loop (cost=1.14..13.53 rows=5 width=1447) (actual time=0.040..0.054 rows=10 loops=1)
-> Nested Loop (cost=0.71..9.79 rows=1 width=994) (actual time=0.027..0.027 rows=1 loops=1)
-> Index Scan using idx_presc_premio_nip on premio_presc_v2 a (cost=0.29..3.91 rows=2 width=577) (actual time=0.012..0.012 rows=1 loops=1)
Index Cond: (nip = 200903667)
-> Index Scan using idx_dsi_cycle on dsi_presc_cycle b (cost=0.42..2.93 rows=1 width=417) (actual time=0.013..0.013 rows=1 loops=1)
Index Cond: (idpres = a.id)
Filter: (cycle = 2)
Rows Removed by Filter: 2
-> Index Scan using idx_presc_jour_premio1 on premio_presc_jour_produit c (cost=0.43..3.48 rows=26 width=453) (actual time=0.010..0.020 rows=10 loops=1)
Index Cond: (idcycle = b.id)
Total runtime: 0.178 ms
Sauriez-vous pourquoi pgadmin prends plus de temps à afficher le résultat depuis la 9.3 alors que normalement, les requêtes devraient être plus rapide sur la 9.3 (cf explain), ce qui d'ailleurs se vérifie par exemple via une connexion jdbc: la requête en 9.3 prends 3ms, tandis qu'en 9.6, c'est 4ms.
Question annexe: est-on censé gagner sérieusement en perf en passant de la 9.3 à la 9.6?
Dernière modification par olivier.bouiron (18/08/2016 12:27:46)
Hors ligne
#2 18/08/2016 12:28:31
- olivier.bouiron
- Membre
Re : PgAdmin et Postgres 9.6 vs 9.3
Désolé je viens de voir que je ne suis pas dans la partie pgadmin...
Hors ligne
#3 18/08/2016 12:55:18
- rjuju
- Administrateur
Re : PgAdmin et Postgres 9.6 vs 9.3
À priori, vos jeux de données sont différents, et un LIMIT sans ORDER BY ne vous garantit pas de retourner toujours les mêmes lignes.
Sinon, un EXPLAIN (ANALYZE, BUFFERS) aiderait à voir s'il s'agit d'un problème de cache.
Julien.
https://rjuju.github.io/
Hors ligne
#4 18/08/2016 13:14:13
- gleu
- Administrateur
Re : PgAdmin et Postgres 9.6 vs 9.3
De toute façon, la différence entre 3 et 4ms est tellement ridicule que l'on peut rien en conclure.
Guillaume.
Hors ligne
#5 18/08/2016 14:12:17
- olivier.bouiron
- Membre
Re : PgAdmin et Postgres 9.6 vs 9.3
Effectivement, mais c'est justement ça qui me surprends, c'est que l'execution est quasi la même sur les deux serveurs, mais que le rappatriement des datas via pgadmin prends 2x plus de temps sur le serveur 9.3.
Dernière modification par olivier.bouiron (18/08/2016 14:14:17)
Hors ligne
#6 18/08/2016 15:04:59
- rjuju
- Administrateur
Re : PgAdmin et Postgres 9.6 vs 9.3
Surtout que l'écart de temps est probablement du au contenu des données (transit réseau, affichage dans pgAdmin) plutôt qu'au traitement de la requête par le serveur.
Julien.
https://rjuju.github.io/
Hors ligne
#7 18/08/2016 15:15:19
- olivier.bouiron
- Membre
Re : PgAdmin et Postgres 9.6 vs 9.3
Surtout que l'écart de temps est probablement du au contenu des données (transit réseau, affichage dans pgAdmin) plutôt qu'au traitement de la requête par le serveur.
Ce sont les mêmes datas qui sont renvoyées, j'ai ajouté un order by pour prendre les mêmes lignes.
Aprés, c'est vrai que ce n'est pas trés important mais c'était par curiosité.
Hors ligne
Pages : 1