L'auteur est Tim Perdue, le développeur du site Sourceforge justement. Il a testé Postgres 7.1
avec le code actuel de Sourceforge (légèrement remanié pour l'adapter à Pg). Et contrairement
a ce qui a été dit plus haut ce n'est pas du code optimisé Pg mais plustôt MySQL.
Et Tim Perdue est plutôt un défenseur de MySQL habituellement.
Le résultat, c'est que la génération des pages est très nettement plus rapide avec Postgres,
jusqu'à 6 fois sur une page très compliquée.
La raison à cela, c'est que MySQL n'est rapide que si on respecte les deux conditions suivantes :
Un tout petit nombre d'accès concurent (5-10 max.) et peu d'accès en écriture.
Dans les autres conditions MySQL s'éffondre littéralement.
On peut très souvent lire des témoignages de gens qui on obtenu de meilleures performances avec un test rudimentaire,
simplement en lancant un script ou me une seule requête. Ces tests ne vallent pas grand chose pour gauger un SGBD.
Les SGBD ont avant tout été conçu pour gérer la cohérence des données lors des accès concurents à celles-ci.
Si on a pas besoin d'accès concurent, il vaut mieux faire des fichiées hachés, c'est plus performant car on
évite le codage-décodage en SQL et le trafic réseau.
Quant aux transactions, c'est indispensable à la cohérence des données lors d'ajout fréquents,
(évidement quand on ne fait que des lectures...) et bien sûr ça se paye en performance.
[^] # Re: C'est pas RDBMS et alors ?
Posté par Smylo . En réponse à la dépêche Comparaison MySQL / PostgreSQL. Évalué à 1.
Visiblement non....
L'auteur est Tim Perdue, le développeur du site Sourceforge justement. Il a testé Postgres 7.1
avec le code actuel de Sourceforge (légèrement remanié pour l'adapter à Pg). Et contrairement
a ce qui a été dit plus haut ce n'est pas du code optimisé Pg mais plustôt MySQL.
Et Tim Perdue est plutôt un défenseur de MySQL habituellement.
Le résultat, c'est que la génération des pages est très nettement plus rapide avec Postgres,
jusqu'à 6 fois sur une page très compliquée.
La raison à cela, c'est que MySQL n'est rapide que si on respecte les deux conditions suivantes :
Un tout petit nombre d'accès concurent (5-10 max.) et peu d'accès en écriture.
Dans les autres conditions MySQL s'éffondre littéralement.
On peut très souvent lire des témoignages de gens qui on obtenu de meilleures performances avec un test rudimentaire,
simplement en lancant un script ou me une seule requête. Ces tests ne vallent pas grand chose pour gauger un SGBD.
Les SGBD ont avant tout été conçu pour gérer la cohérence des données lors des accès concurents à celles-ci.
Si on a pas besoin d'accès concurent, il vaut mieux faire des fichiées hachés, c'est plus performant car on
évite le codage-décodage en SQL et le trafic réseau.
Quant aux transactions, c'est indispensable à la cohérence des données lors d'ajout fréquents,
(évidement quand on ne fait que des lectures...) et bien sûr ça se paye en performance.