IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

PostGreSQL vs Microsoft SQL Server - Partie 2 : performances des requêtes avec COUNT
Par Frédéric BROUARD (SQLpro)

Le , par Malick

40PARTAGES

14  0 
Chers membres du club,

J'ai le plaisir de vous présenter la deuxième partie de cet article de SQLpro :

PostGreSQL vs Microsoft SQL Server
Partie 2 : performances des requêtes avec COUNT
Ce second article compare PostGreSQL à SQL Server et met en avant les différences de performances des requêtes d’agrégation qui utilisent la fonction COUNT.

Notre premier article comparait les temps de réponse entre PostGreSQL et SQL Server des requêtes administratives que les DBA doivent ordinairement exécuter.
Bonne lecture

Retrouvez les meilleurs cours et tutoriels pour apprendre les SGBD et SQL
.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de FatAgnus
Membre éprouvé https://www.developpez.com
Le 23/03/2021 à 10:43
Pourquoi s'entêter à mesurer les performances de PostgreSQL alors que personne n'utilise PostgreSQL sous Windows en production et que PostgreSQL fonctionnera certainement plus vite sous Linux que sous Windows comme l'affirme Magnus Hagander l'une des personnes qui a porté PostgreSQL sous Windows sur Stack Exchange · Server Fault :

PostgreSQL fonctionnera certainement plus vite sous Linux que sous Windows (et je dis cela en tant que l'un des gars qui a écrit le portage Windows de celui-ci...) Il est conçu pour une architecture de style Unix, et implémente cette même architecture sous Windows, ce qui signifie qu'il fait un certain nombre de choses que Windows n'est pas conçu pour faire correctement. Il fonctionne bien, mais il n'est pas aussi performant.
J'ai bien peur que ce test n'est que peu d'intérêts. Mais bon L'auteur (un MVP Microsoft) est bien connu pour s'être donné comme mission de faire de la propagande SQL Server au détriment des bases de données open source, et il fait ça depuis très longtemps (voir par exemple son article Découvrez les dangers de MySQL et MariaDB truffés d'erreurs). J'ignore pourquoi l'auteur s'est donnée cette mission, il ne serait pas surprenant qu'il en tire quelques avantages en coulisses.
14  6 
Avatar de SimonDecoline
Expert confirmé https://www.developpez.com
Le 23/03/2021 à 20:13
Citation Envoyé par tanaka59 Voir le message
Tu casses les pieds a toujours intervenir inutilement.

Quand je dis la "gratuité se paye", sur le fond, c'est qu'un produit gratuit se sera toujours moins aboutit qu'un produit payant ...
Désolé mais j'ai autant le droit que toi de m'exprimer. Je pense que ce que tu racontes est du grand n'importe quoi bien plus inutile. Mais je ne te reproche pas de le dire alors merci d'en faire autant.
9  2 
Avatar de FatAgnus
Membre éprouvé https://www.developpez.com
Le 23/03/2021 à 20:14
Citation Envoyé par tanaka59 Voir le message
En dehors de toute considération pour un parti ou un logiciel. Concernant les perfs SQL, la question de fond avoir est la suivante : "en terme d’exécution qu'elle est le SGBD le plus "rapide" ?".
Justement comme l'atteste ces nombreux articles ou commentaires l'auteur Frédéric Brouard a un parti pris contre les bases de données open source depuis des années, donc l'impartialité de Frédéric Brouard porte à suspicion. Mesurer les performances de PostGreSQL sur Windows est juste un moyen de baiser les résultats puisque le port Windows de PostgreSQL n'est pas aussi performant que la version Linux. Et surtout personne n'utilise PostGreSQL sous Windows en production, donc l'intérêt de ce test est sans intérêt, sauf si on veut dénigrer PostGreSQL. On peut faire confiance aux compétences reconnues de Frédéric Brouard pour trouver les tests qui désavantageront PostgreSQL, comme exécuter PostgreSQL sur un système d'exploitation où il est moins performant. Mais l'auteur a sûrement d'autres astuces dans son sac.

Citation Envoyé par tanaka59 Voir le message
Sur l'aspect vitesse d’exécution ou vitesse de traitement, bien évidement qu'un Oracle, MS Server, SAS, Access seront plus rapide ... La gratuité se "paye" . Comment ? Un Wamp ou un MySQL est bon a faire une base d'archive ...
Votre esprit embrumé, confond deux choses. Votre première confusion est la gratuité et l'open source. Un logiciel gratuit n'est pas forcément open source. Ensuite votre deuxième confusion vient de la licence d'un logiciel et de sa performance. À vous croire le fait de publier un logiciel sous licence open source le rendrait moins rapide ? Je ne sais pas si vous êtes conscient de l'absurdité de votre raisonnement. La performance et la licence d'un logiciel sont deux choses distinctes.
10  3 
Avatar de CinePhil
Modérateur https://www.developpez.com
Le 24/03/2021 à 14:37
Même si le ton de FatAgnus, et ensuite les propos de quelques autres, sont quelque peu désagréables à lire (et, en tant que modérateur, j'aimerais bien que la discussion se calme), FatAgnus pose quand même incidemment une question intéressante à laquelle SQLPro pourrait peut-être répondre :

Serait-il possible qu'il fasse les même tests avec les deux SGBD en environnement Linux ?

Comme il avait déclaré lui-même - et il me semble que ça a été confirmé par d'autre tests - que SQL Server est plus rapide sous Linux que sous Windows, ça pourrait être intéressant de voir si les écarts se réduisent ou se creusent.
6  0 
Avatar de pokap
Membre du Club https://www.developpez.com
Le 25/03/2021 à 21:07
Bonjour,

Merci pour le "Tutoriel", je met entre guillemet parce que c'est plutôt un comparatif de temps de réponse.

Je voulais ajouter mon grain de sel à la discussion car on parle de pur performance mais il faut bien comprendre (pour ceux qui vont me lire) que ça n'a aucune valeur de qualité pour le choix d'une base de donnée.
Et comme on est dans une rubrique débutante, je voudrais signaler aux développeur.ses qui cherchent une base de donnée de considérer la performance comme tertiaire à votre choix, si vous prenez une bdd uniquement sur ces performances vous allez planter votre projet c'est garanti.

Ensuite je ne veux pas remettre en doute l'écart affiché de 1000x, en admettant que c'est vrai on est en train de comparer la perf d'une formule 1 à un 2CV en gros, et là c'est problématique car on a l'impression qu'il "suffit" de changer de bdd et hop c'est mieux, hors c'est tout le contraire le choix de la bdd va avec le reste de l'infrastructure, de la compétence des devs et des sys admin, des licences, la communauté, etc. Le choix final repose surtout sur le type de projet qui va avec la bdd. Ça me rappelle l'époque où certaine utilisait des bdd no-sql orienté document ou colonne pour stocker des data de blogs.

Pour finir j'aurais quand même préféré voir un tutoriel sur SQL server pour savoir dans quel cas il serait plus sage de l'utiliser par rapport à d'autres usages. Dans mon cas j'utilise bien Postgresql sur un projet en production avec des tables de + de 10M de row et je n'ai aucun soucis de temps de réponse avec (~40ms pour les plus lourd avec plusieurs jointures - sans aucun cache - 8 cores 64 Go - debian).
7  1 
Avatar de destroyedlolo
Membre régulier https://www.developpez.com
Le 26/03/2021 à 2:32
Salut,

En fait, je ne voulais pas rentrer dans ce sempiternel thread : m$ vs le reste du monde mais ...

Citation Envoyé par SQLpro Voir le message
Croire que PostGreSQL est aussi bon que SQL Server est une vaste fumisterie tant ses bugs et errement fonctionnels sont nombreux.
Ca fait bientôt 15 ans que que j'ai une base qui emmagasine tous plein de données environnementales, avec évidemment des upgrades successifs et j'utilise pgsql pour pleins de projets que ce soit en hobby comme en PRO. En 15 ans, j'ai eu en tout et pour tout : 1 BUG, ouai, 1 seul bug, liée a pg_dump uniquement lorsqu'on l'utilise en mode texte. Un bug qui a été corrigé rapidement.
Et que ce soit pour cette base, ou pour les autres projets sur lesquels j'ai été amener a bosser : JAMAIS aucune perte de donnée, JAMAIS aucune corruption, JAMAIS une requete qui faisait autre chose que ce qui lui était demandé. J'ai eu certe des pb de perfs, mais jamais la moindre données n'a été perdue (hors erreur humaine bien sur ou disque HS).
Alors évidement, ma propre expérience ne peut pas etre érigée comme "une vérité vraie", mais je n'ai JAMAIS eu la même expérience avec le moindre outils microsoft : car niveau bugs, on peut difficilement mettre cette boite en avant vu l'histoire plus que chaotiques de leurs produits a commencer par ms-windows.

Je n'utilise pas Sqlserver, car je n'ai simplement pas confiance. Peut etre un très bon produit, mais je ne prendrais pas le risque !

Dire que "PostgreSQL est plus buggé" laisse juste entrevoir une mauvaise fois presque aussi forte que la mienne
6  1 
Avatar de FatAgnus
Membre éprouvé https://www.developpez.com
Le 27/03/2021 à 15:11
Citation Envoyé par SQLpro Voir le message
Ce qui est bien évidemment totalement faux.... mais il est vrai que le nombre de serveur PG sous Windows diminue au fil du temps..
Vous avez des statistiques d’utilisation de PostgreSQL sous Microsoft Windows et GNU/Linux ? Si effectivement la société Microsoft peut prétendre connaître le nombre d'instances de Microsoft SQL Server (avec des techniques de télémétrie ou de pistage de ses utilisateurs), PostgreSQL ne piste pas ses utilisateurs. Expliquez nous l'intérêt de payer une licence Microsoft Windows Server pour exécuter PostgreSQL qui sera beaucoup moins rapide sur sur la même serveur sous GNU/Linux ?
Citation Envoyé par SQLpro Voir le message
C'est probable et notez que c'est la même chose avec SQL Server dans les tests que nous avons effectué dans cette étude :
https://sqlpro.developpez.com/tutori...windows-linux/
Vous mélangez tout, et bien sûr recherche de la vérité n'est pas votre objectif. Comme, vous le savez sûrement depuis longtemps, le développeur Magnus Hagander affirme que PostgreSQL est conçu pour une architecture de style Unix, et n'a pas du tout été optimisé pour Microsoft Windows. Ce n'est un secret pour personne. On peut supposer que le portage de Microsoft SQL Server pour GNU/Linux est de meilleure qualité.

Citation Envoyé par SQLpro Voir le message
Néanmoins, ces gains de performance sont marginaux par rapport à des écarts de plus de 1000 fois !
Comme le dit justement une personne dans le reportage sur ARTE La fabrique de l'ignorance, on peut fait dire ce qu'on veut à une étude, il suffit de trouver le protocole de test qui vous arrange.

Citation Envoyé par SQLpro Voir le message
Ah oui ? Allez donc dire à des clients qui passent de l'un à l'autre et constatent que leurs requêtes de comptage sont mille fois plus lente mais que cela n'a aucun intérêt....
Vous faites cette étude pour vos clients ou pour les lecteurs de Developpez.com ? Si vos clients sont la société Microsoft, je comprends mieux vos résultats.

Citation Envoyé par SQLpro Voir le message
Ce que ne font pas, bien entendu les tenants du libre dans des articles bidons farcis d'erreurs comme celui-ci qui est une honte pour EnterpriseDB et que je démolirais pièce par pièce dans la 3e partie de ma série d'articles :
https://www.enterprisedb.com/blog/mi...at-differences
Tout le monde aura compris que vous êtes là, je vous cite pour « démolir » les bases de données open source et libres et non pour publier des tests impartiaux. Ce que vous faites très bien depuis des années, je le concède.

Citation Envoyé par SQLpro Voir le message
Lesquelles ? Au lieu de dénigrer, donnez quelques exemples des erreurs que j'ai commises !
En terme de dénigrement, vous n'avez rien à apprendre. J'ai déjà publié un commentaire pointant vos grossiers mensonges : dénigrement du nom « MySQL » qui signiferait « mon petit business », utilisation de benchmarks mesurant les performance de MySQL 5.6 sorti en février 2013 dans un article de 2019 ; peur, incertitude et doute sur des mesures RGPD de sociétés dont rien ne dit qu'elles utilisent MySQL, tromperie sur la taille du code et la taille d'installation ; confusion volontaire entre l'outil de suivi de de problèmes de MySQL avec un outil de feedback des utilisateurs de Microsoft SQL Server ; assimilation trompeuse du nombre de bugs ouverts de MySQL avec la qualité du produit...

Quand on s'attaque à une comparaison des performances, ou autres, entre deux logiciels, les principales qualités sont l'exactitude, la rigueur, l'impartialité et la courtoisie. Qualités qui malheureusement vous semblez dépourvues.
8  3 
Avatar de SimonDecoline
Expert confirmé https://www.developpez.com
Le 31/03/2021 à 17:24
Citation Envoyé par SQLpro Voir le message
le nombre de bug (car les vulnérabilités exposées sont des bugs) sont proportionnelles au nombre de ligne de code, donc au volume en octet des exécutables...
D'un côté, tu nous dis que l'open-source expose naturellement à plus de vulnérabilités, du fait de la disponibilité du code. Et d'un autre côté, tu nous dis que les failles découvertes sont proportionnelles au nombre de lignes de code...
7  2 
Avatar de SimonDecoline
Expert confirmé https://www.developpez.com
Le 24/03/2021 à 13:28
Citation Envoyé par sinople Voir le message
je vois pas le problème considérant que developpez.com n'est pas un site de recherche universitaire et qu'à priori c'est accepté par la rédaction du site.
Tout à fait. Donc heureusement qu'il y a des messages comme ceux de FatAgnus pour expliciter la situation.

Enfin si, il y a quand même un problème : le risque que dvp finisse par avoir la même crédibilité technique que 4chan ou que blabla 15-18 sur JVC...
6  2 
Avatar de Waldar
Modérateur https://www.developpez.com
Le 24/03/2021 à 15:33
Petit rappel, le code et la configuration utilisés par SQLPro lors de ces benchmarks sont disponibles, libre à tout-à-chacun de faire ses propres benchs, et je vous l'annonce, les résultats seront différents.

Entre les versions d'OS, des logiciels et les différentes configurations matérielles et logicielles il y a un nombre suffisamment grand de combinaison possible qui font qu'il n'y aura jamais de comparatif empirique.

SQLPro défini un benchmark, pose une brique et tire les conclusions sur ce bench.
Le titre fait venir les lecteurs - et provoque les débats - c'est discutable mais ce n'est pas comme si c'était le seul au monde à utiliser cette technique.
4  0