Bref, faites vos benchs si vous le souhaitez, bien sûr. Il n'y aura vraisemblablement rien de magique, Postgres a toujours été optimisé pour les systèmes Unix. Mais si vous obtenez des chiffres allant dans l'autre sens, pourquoi pas, ça pourrait être un témoignage intéressant pour nuancer tout ce qui a été mis en évidence jusque là.
Par contre, personne n'a parlé de la fiabilité de windows dans aucun message du thread. Je ne vois pas ce qui vous a poussé à le mentionner…
]]>D'un autre côté, ça serait une première d'avoir un benchmark où la version PostgreSQL pour Windows serait devant la version Unix.
Par contre, je pense qu'une base de 20Go, avec 4Go de RAM sur le serveur, ça ne va pas intéresser grand monde.
]]>Pour ce qui est des performances de PostgreSQL sous Windows, il y a un coût, qui dépend des types de requêtes et d'usage, mais est souvent mesuré à 20 à 30%, par rapport aux performances de la même machine sous Linux. Tout simplement parce que PostgreSQL est écrit pour des systèmes Unix, utilise des appels système Unix en permanence (fork, mémoire partagée système 5, sémaphores, etc…) et que sous Windows, il y a une (fine, sauf pour fork) couche d'émulation. D'où la question de Damien. Mais il est tout à fait possible que ça soit un test sur lequel ça aurait eu peu d'impact.
Ce serait intéressant de creuser ce point sur un même serveur. En gros, jouer une dizaine de requêtes sur une volumétrie non négligeable (du gendre base 20 Go RAM 4 Go) et voir les différences entre Windows et Linux. mais je ferais le pari qu'avec Windows 2008 R2, PostGreSQL arrive en tête par rpport à Linux sur les requêtes à forte volumétrie !!! Je suis prêt à parier une caisse de champagne !
A +
]]>Par contre, pour information, un module aurait certainement permis de gratter un peu plus de performances sur PostgreSQL: l'utilisation du type «temporal», disponible en 9.0 (avec les opérateurs d'union d'intervalles déjà tout écrits, et le fait que les index sont utilisables pour détecter les intervalles en intersection avec d'autres, par exemple). Enfin, c'est un module à ajouter, mais ça se fait assez facilement.
http://temporal.projects.postgresql.org/reference.html
Pour ce qui est des performances de PostgreSQL sous Windows, il y a un coût, qui dépend des types de requêtes et d'usage, mais est souvent mesuré à 20 à 30%, par rapport aux performances de la même machine sous Linux. Tout simplement parce que PostgreSQL est écrit pour des systèmes Unix, utilise des appels système Unix en permanence (fork, mémoire partagée système 5, sémaphores, etc…) et que sous Windows, il y a une (fine, sauf pour fork) couche d'émulation. D'où la question de Damien. Mais il est tout à fait possible que ça soit un test sur lequel ça aurait eu peu d'impact.
]]>Étant donné le test, difficile de dire ce qui fait la différence. Je présume (j'ai regardé très vite l'exemple) que c'est avant tout l'acquisition de verrous sur les enregistrements de cette table de compteur qui dure longtemps sur le test ?
S'agissant de lectures, cela influe peu...
Non je dirais ce qui fait la différence avec MS SQL Server c'est l'utilisation de l'opérateur CROSS APPLY. Microsoft à proposé sa normalisation au comité. SQL...
A +
]]>Pourquoi le choix de PostgreSQL 8.4 ? La version 9.0 aurait probablement donné de meilleures performances...
Bonne remarque. Mais j'attends en général toujours 1 an avant de prendre la version suivante par soucis de sécurité. Cependant, dès que j'ai le temps je vais refaire des tests avec la version 9.
Par ailleurs vous n'indiquez pas le profile matériel et OS de la plateforme de test. J'imagine que vous avez utilisé Windows ?
Si toutes les plateformes sont mentionnées (voir paragraphe CONDITION DES TESTS). Les tests comparatif ont été effectué sur Windows, évidemment, car SQL Server n'est pas disponible sous Linux.
Ceci dit, cela ne change rien à mon sens. Je dirais même qu'il y aurait un léger désavantage, car les formats de page de données étant plus petits un extra overhead va s'ajouter sur les parcours.
De plus il faudrait formater la même machine sous Linux et Windows pour que le test soit équitable... Si quelqu'un veut le faire, je prête mon HP Proliant DL 385 G2 pour ce faire !!!!
A +
]]>Par ailleurs vous n'indiquez pas le profile matériel et OS de la plateforme de test. J'imagine que vous avez utilisé Windows ?
]]>Pour information, ce petit benchmark concernant un besoin d'extraction de données.
La question est simple... Partant d'une table de période de temps, agréger les périodes recouvrantes par item, pour n'en avoir plus que l'essentiel... (packing d'intervalles).
Tests effectuées sur MySQL version 5.5, PostGreSQL version 8.4 et MS SQL Server version 2008 R2 avec des jeux d'essais allant de 1 000 à 3 000 000 de lignes.
Résultats :
* PotsGreSQL est entre 3 et 13 fois moins rapide que SQL Server
* MySQL est entre 59 et 5 947 fois moins rapide que SQL Server
...en fonction de la montée en charge.
Bref, une excellente surprise pour PostGreSQL qui confirme grandes fonctionnalités, qualités et performances dans le monde des SGBDR libre !
Tous les détails, les conditions et les scripts SQL pour rejouer ce benchmark chez vous sur : http://blog.developpez.com/sqlpro/p9826 … -avec-sql/
A +
]]>