Discussion :

[sinople]

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 :



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.

J'ai un sérieux doute que beaucoup de professionnel s'amuse à mélanger des stacks Windows avec des stacks Linux.

Ce qui me fait dire que ce test est un peu un enfonçage de porte ouverte, mais qu'un comparatif SQL Server sur Windows vs PostgreSQL sur Linux aurait finalement le même intérêt vu que je trouve extrêmement réducteur de limiter le choix d'une stack sur une histoire de performance de DB.

Probablement que ce papier a une raison commerciale liée à une obligation de faire de la présence communautaire. C'est du même niveau que les intégrateurs qui organisent des ateliers sur un produit dont ils sont partenaires et 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.

[Invité]

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...

[CinePhil]

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.

[Waldar]

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.

[steel-finger]

SQLPro il aurait été bien de proposé des solutions pour PostgreSQL dans votre benchmark car juste de dire c'est plus rapide sur SQL Server, au moins ça aurait permis de donner des conseils voir de l'info aux gens lisant votre post !

Edit: Les testes sont fait sur SSD ou HDD ?

[chrtophe]

Comme dit par d'autres membres, il aurait été intéressant d'avoir un bench avec une version Linux, ça me parait un minimum pour un bench avec une vraie valeur.

Je ne suis pas spécialiste en base de données, mais l'écart étant tellement important, je me demande si il n'y a pas des optimisations à appliquer sur chaque SGBD pour pouvoir faire une vraie comparaison.

Il se peut également que SQL-Server soit meilleur en certain point et moins bon sur d'autres par rapport à PostGres. Ne montrer ces points spécifiques biaise les résultats

[RenardSpatial]

Je me permet de déterrer ceci :

J'assume parfaitement ce qui vous apparait comme une erreur typographique et qui est ma signature de tout temps au sujet de PostGreSQL. Sachez que les noms n'ont pas d'orthographe précise et que PostGreSQL n'est visiblement pas une "trademark". On n'est donc pas obligé de respecter la typologie de la communauté (ou serait donc la liberté si on me l'imposait comme semble vouloir me le faire remarquer les intégristes de PG...). De plus PostGreSQL c'est la suite de InGreSQL (notez là aussi le G majuscule, que je n'utilise en principe jamais pour Ingres....) un simple jeu de mot ayant guidé le choix de PostGreSQL à l'origine PostGres (sans le SQL) qui signifie après "gres" alors qu'avant c'était dans "gres". C'est là sans doute mon aspect vieux con qui après 34 ans passé dans les SGBDR m'en a fait connaître l'histoire et les principaux (DB2, Oracle, Sybase SQL Server, Watcom, RDB, Gupta SQL, Informix, InterBase et bien d'autres....) pour ne plus me consacrer qu'à quelques uns (MS SQL Server, Oracle, PostGreSQL...).

Parce que j’ai appris depuis votre réponse que, contrairement à ce que vous avancez, PostgreSQL est bien une trademark et s’écrit donc bien sans « g » majuscule. En particulier, les conditions d’utilisation disent ceci (section How To Use Our Marks, premier point) :

The marks should not be modified in any way without prior approval.

[SQLpro]

Je me permet de déterrer ceci :

Parce que j’ai appris depuis votre réponse que, contrairement à ce que vous avancez, PostgreSQL est bien une trademark et s’écrit donc bien sans « g » majuscule. En particulier, les conditions d’utilisation disent ceci (section How To Use Our Marks, premier point) :

Déjà répondu ici : https://www.developpez.net/forums/d2.../#post11680155

Honnêtement on s'en fou ! Est-ce cela aura une influence sur les résultats désastreux de PostGreSQL en termes de performances ?

A +

[SQLpro]

J'ai l'impression qu'il manque un bout des résultats ; je n'ai que le chapitre "XII. Performances du COUNT sans aucun index", un tableau de résultat et ensuite des conclusions qui parlent d'index Btree & ColumnStore.

Tu as raison, il manque pas mal de bout d'article qui ont été perdu dans la nature. L'article original est sur mon site :
En VF : http://mssqlserver.fr/postgresql-vs-...es-avec-count/
En anglais : http://mssqlserver.fr/postgresql-vs-...-performances/

Je lance la rectif des choses perdues

A +

[SQLpro]

Comme dit par d'autres membres, il aurait été intéressant d'avoir un bench avec une version Linux, ça me parait un minimum pour un bench avec une vraie valeur.

Je ne suis pas spécialiste en base de données, mais l'écart étant tellement important, je me demande si il n'y a pas des optimisations à appliquer sur chaque SGBD pour pouvoir faire une vraie comparaison.

Il se peut également que SQL-Server soit meilleur en certain point et moins bon sur d'autres par rapport à PostGres. Ne montrer ces points spécifiques biaise les résultats

Je dispose de deux serveurs physique HP DL 385 avec 8 disques SAS 300 Go, l'un avec Linux l'autre avec Windows.
Je les met à disposition de qui veut s'en occuper car n'étant pas spécialiste Linux, j'ai peur de ne pas être au top, et donc d'être à nouveau victime de critiques acerbes des ayatollah du pingouin !

A +

[RenardSpatial]

Déjà répondu ici : [url]https://www.developpez.net/forums/d2101921/bases-donnees/decisions-sgbd/debuter/postgresql-vs-microsoft-sql-server-partie-1-performances-commandes-dba/#post11680155[/url

Vous ne répondez pas à grand-chose, puisque vous vous contentez de renvoyer vers le message que je citais en en-tête et pour lequel je réfutais le point principal (à savoir : que l’on pourrait écrire « PostgreSQL » comme on veut puisque le terme ne serait pas protégé, hors il l’est).

Notez bien qu’on ne parle pas de performances ici mais de droit des marques, et que ce message s’adresse autant à developpez.[com|net] en tant qu’éditeur qu’à vous en tant qu’auteur, puisqu’en maintenant ces publications sur les articles vous vous rendez coupable de violation de propriété intellectuelle. Après on peut partir du principe que probablement PostgreSQL n’attaquera personne ici : on est surtout dans une question d’image de sérieux et de professionnalisme pour developpez.[com|net] et de ses auteurs.

[SQLpro]

Pourquoi s'entêter à mesurer les performances de PostgreSQL alors que personne n'utilise PostgreSQL sous Windows en production

Ce qui est bien évidemment totalement faux.... mais il est vrai que le nombre de serveur PG sous Windows diminue au fil du temps...

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 ...

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/
Néanmoins, ces gains de performance sont marginaux par rapport à des écarts de plus de 1000 fois !

J'ai bien peur que ce test n'est que peu d'intérêts.

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....

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,

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

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).

Lesquelles ? Au lieu de dénigrer, donnez quelques exemples des erreurs que j'ai commises !


A +

[SQLpro]

Vous ne répondez pas à grand-chose, puisque vous vous contentez de renvoyer vers le message que je citais en en-tête et pour lequel je réfutais le point principal (à savoir : que l’on pourrait écrire « PostgreSQL » comme on veut puisque le terme ne serait pas protégé, hors il l’est).

Notez bien qu’on ne parle pas de performances ici mais de droit des marques, et que ce message s’adresse autant à developpez.[com|net] en tant qu’éditeur qu’à vous en tant qu’auteur, puisqu’en maintenant ces publications sur les articles vous vous rendez coupable de violation de propriété intellectuelle. Après on peut partir du principe que probablement PostgreSQL n’attaquera personne ici : on est surtout dans une question d’image de sérieux et de professionnalisme pour developpez.[com|net] et de ses auteurs.

Visiblement vous ne savez pas lire. Il est protégé au niveau du fond, pas de la forme. Si vous ne faites pas la différence entre les deux concepts, bien des choses s'expliquent !

A +

[RenardSpatial]

Visiblement vous ne savez pas lire. Il est protégé au niveau du fond, pas de la forme. Si vous ne faites pas la différence entre les deux concepts, bien des choses s'expliquent !

J’ai peur que la page que j’ai cité dans mon premier message à ce sujet parle bien de la forme :

The marks should not be modified in any way without prior approval.

Et le terme mark désigne bien les mots « Postgres » ou « PostgreSQL » comme c’est dit au début de la même page :

TSpecifically, the terms Postgres and PostgreSQL and the Elephant Logo (Slonik) are all registered trademarks

---

Pour qui voudrait des références de droit international sur ce que je raconte :

(1) A trademark shall protect a sign which may be represented graphically and which is
capable of distinguishing the goods or services of one undertaking from those of other
undertakings.
(2) Trademarks may protect signs, in particular: words, letters, numerals, abbreviations,
graphical representations, combinations of colours and the tints thereof, three-dimensional forms,
shapes of the goods or the packaging thereof, provided that they are distinctive, as well as the
combinations of all the above indicated signs.
(3) A seal, a stamp and a hallmark (official mark identifying precious metals, measures,
etc.) shall not, under this Law, be considered to be trademarks.

Source : TRADEMARK LAW, Part One, BASIC PROVISIONS : The Concept of a Trademark sur le site officiel de l’Organisation Mondiale du Commerce, donc l’instance internationale chargée de s'assurer que les règles commerciales (dont le droit des marques) est harmonisé autant que possible internationalement. On retrouve des dispositions similaires à ce texte tant en droit US qu'en Europe.

PS : la transcription en droit européen :

TITRE II

DROIT DES MARQUES

SECTION 1

Définition et acquisition de la marque communautaire

Article 4

Signes susceptibles de constituer une marque communautaire

Peuvent constituer des marques communautaires tous les signes susceptibles d'une représentation graphique, notamment les mots, y compris les noms de personnes, les dessins, les lettres, les chiffres, la forme du produit ou de son conditionnement, à condition que de tels signes soient propres à distinguer les produits ou les services d'une entreprise de ceux d'autres entreprises.

Source : Le journal officiel de l’Union Européenne

[SQLpro]

Pour qui voudrait des références de droit international sur ce que je raconte :

Pour qui voudrait des références de droit international sur ce que je raconte :

(1) A trademark shall protect a sign which may be represented graphically and which is
capable of distinguishing the goods or services of one undertaking from those of other
undertakings.
(2) Trademarks may protect signs, in particular: words, letters, numerals, abbreviations,
graphical representations, combinations of colours and the tints thereof, three-dimensional forms,
shapes of the goods or the packaging thereof, provided that they are distinctive, as well as the
combinations of all the above indicated signs.
(3) A seal, a stamp and a hallmark (official mark identifying precious metals, measures,
etc.) shall not, under this Law, be considered to be trademarks.

Pour votre information une marque graphique est un logo. Or le ! 1) ne concerne pas le littéral.
le 2) concerne les littéraux et il n'est pas fait mention, ni de la casse, ni de la police, ni du gras, du souligné ni de l'italique...
Rien dans le dépôt de marque de PostgreSQL ne parle ni de la casse ni de la police, ni du gras, du souligné ni de l'italique...
Pour information, le dépôt de marque de la compagnie IBM, précise bien que :
"Do not misspell or use lower case letters when using the name IBM in text."
https://www.ibm.com/legal/copytrade

Donc, j'ai parfaitement le droit de mettre des majuscules et minuscules ou je veut dans le nom de PoStGrEsQl !

Il faut savoir lire !

A +

[pokap]

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).

[destroyedlolo]

Salut,

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

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

[chrtophe]

Le débat parle ici d'un comparatif entre PostGreSQL vs MS-SQL, pas de logos ni de trademarks. Ceci n'apporte absolument rien au débat. Si vous n'êtes pas d'accord, c'est tout à fait votre droit. Mais donnez de vrais arguments.

Il serait intéressant de tester sous Linux pour l'écart que cela représente.

Et il faut comparer ce qui est comparable, avec les mêmes options d'optimisations sur les deux plateformes, ce qui peut être très difficile (options/fonctionnement différent). Le fait de ne pas être sur le même FS peut aussi biaiser les résultats.

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.

Pour SQL-Pro c'est clairement MS-SQL, et il ne s'en cache pas. Mais d'un autre coté c'est un expert du produit. Quelle que soit l'utilisation, il pourra très facilement faire en sorte d'avoir la meilleure optimisation possible. Si maintenant il est forcé de faire un projet avec PostGreSQL, maitrisant moins le produit, il est logique qu'il puisse moins bien l'optimiser, mais dans ce cas là il serait malhonnête de dire que PostGreSQL est moins bon.

Si maintenant, on se place du coté d'un responsable financier, celui-ci pourra très bien considérer PostGreSQL comme plus intéressant par sa gratuité du produit. Mais ce ne sera pas forcément le cas pour le responsable informatique, pour qui de son point de vue verra qu'il est plus facile de trouver des compétences MS-SQL que PostGReSQL.

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.

Ceci peut être également reproductible avec MS-SQL je pense.

Ensuite je pense que pour faire un test juste et impartial, il faut connaitre à minima les deux produits.

Mais tout ça c'est un peu comme comparer un moteur essence et un moteur Diesel :

A puissance égale, un moteur essence et son alter ego diesel délivrent des performances brutes similaires. Mais selon la plage d’exploitation, l’agrément de conduite est bien différent.

[frost242]

Peut-être hors de propos, mais j'ai pris une base Oracle sur un Exadata, la même base passée à la moulinette ora2pg. A chaque fois que je teste une requête, PostgreSQL va plus vite. Imaginez un peu si sqlpro faisait un comparatif sqlserver vs oracle exadata !!

[chrtophe]

Encore une fois il faut comparer ce qui est comparable. Ta solution c'est du cloud (du moins je pense), mais tu n’indiques pas les infos sur l'infra : machine dédiée ou mutualisée, type de disque, RAM, etc.

Ton comparatif est donc biaisé.

Imaginez un peu si frost242 faisait un comparatif PostGres vs oracle exadata !!