La présent article compare les performances de requêtes basiques du système d’information géographique de PostGreSQL (v 9.6.1) et de SQL Server (version 2016).
Comparaison des performances de SIG
PostGreSQL/PostGIS vs SQL Server Spatial
Choisissez la catégorie, puis la rubrique :
La présent article compare les performances de requêtes basiques du système d’information géographique de PostGreSQL (v 9.6.1) et de SQL Server (version 2016).
Comparaison des performances de SIG
PostGreSQL/PostGIS vs SQL Server Spatial
Vous devez être connecté(e) pour rédiger un commentaire.
© 2000-2020 - www.developpez.com
Partenaire : Hébergement Web
Le comparatif était basé sur un « out of the box » des SGBDR…
En optimisant PostGreSQL comme ceci :
### cache
shared_buffers = 2GB
temp_buffers = 64MB
work_mem = 1GB
effective_cache_size = 4GB
### parallelisme
max_worker_processes = 32
max_parallel_workers_per_gather = 16
Bien entendu le Service PostGreSQL a été redémarré.
Et les résultats pour les 4 plus grosses requêtes, avec une moyenne sur 3 relances, après un essai pour la mise en cache :
Q3 est à 58 s. Pas de changement significatif (plutôt moins bon)…
Q10 est à 49 s. Pas de changement significatif.
Q5 est à 32 s. Pas de changement significatif.
Q7 est à 6 s. Changement significatif du à un balayage en parallèle
Bref, absolument aucun changement comme je le prévoyais, apporté par la gestion du cache, du fait du faible jeu de données….
En revanche, un changement significatif de la requête Q7 du fait de la gestion du parallélisme. Le temps a été divisé par 3 mais reste encore 20 fois plus lent que SQL Server !
A +
Merci pour votre article très intéressant.
Je ne connais pas SQL server (gis), seulement Postgresql. Je trouve dommage que vous n’ayez pas réglé à minima les paramètres de PG.