Mysql est souvent plus rapide (ca dépend des insctructions) et stable, mais il est à noter que pgsql devient de plus en plus rapide et stable et mysql dispose de plus en plus de fonctionnalités.
On peut donc dire qu'ils vont vers le même point.
MySQL est souvent plus rapide, mais en cas de requêtes complexes, Postgresql est supérieur (il a un optimiseur complexe, et même un mode par algo génétique pour les requêtes vraiment complexes). De plus, si on ajoute tout ce que peut faire Postgres "tout seul" : triggers, procédures stockées, contrôle d'intégrité (foreign keys), il est beaucoup plus puissant.
Question stabilité, je n'ai jamais planté Postgres (ainsi qu'un ami qui en a sur ses serveurs en production); alors que MySQL a eu la réputation d'être plantable (d'où les outils de récupération de table ISAM).
Je crois qu'une grosse amélioration qui a été apportée à Postgres, c'est le "vacuum" sans verrouillage de table. Le vacuum effectue une sorte de défragmentation, et jusqu'à un version récente, il revenait à rendre la base plus ou moins inutilisable, ce qui est un problème si la base doit fonctionner 24h/24. Le vacuum ("vide" en anglais) réduit la taille des fichiers de la base (élimine les trous).
La fragmentation est dûe au modèle de MVCC = Multi-Version Concurrency Control, qui permet l'isolation des transactions, ce qui veut dire qu'on peut être plusieurs à modifier la base en même temps et chacun ne voit que ses modifs, tant que ce n'est pas "commité". La fragmentation sera d'autant plus forte qu'il y aura des mise à jour (update), bien entendu si on fait surtout des select, la fragmentation sera faible. Je ne sais pas s'il est forcément nécessaire de faire des vacuum souvent, il faudrait mesurer l'impact sur les performances.
[^] # Re: Question stupide
Posté par Olivier Jeannet . En réponse à la dépêche MySQL 4.1 disponible!. Évalué à 5.
On peut donc dire qu'ils vont vers le même point.
MySQL est souvent plus rapide, mais en cas de requêtes complexes, Postgresql est supérieur (il a un optimiseur complexe, et même un mode par algo génétique pour les requêtes vraiment complexes). De plus, si on ajoute tout ce que peut faire Postgres "tout seul" : triggers, procédures stockées, contrôle d'intégrité (foreign keys), il est beaucoup plus puissant.
Question stabilité, je n'ai jamais planté Postgres (ainsi qu'un ami qui en a sur ses serveurs en production); alors que MySQL a eu la réputation d'être plantable (d'où les outils de récupération de table ISAM).
Je crois qu'une grosse amélioration qui a été apportée à Postgres, c'est le "vacuum" sans verrouillage de table. Le vacuum effectue une sorte de défragmentation, et jusqu'à un version récente, il revenait à rendre la base plus ou moins inutilisable, ce qui est un problème si la base doit fonctionner 24h/24. Le vacuum ("vide" en anglais) réduit la taille des fichiers de la base (élimine les trous).
La fragmentation est dûe au modèle de MVCC = Multi-Version Concurrency Control, qui permet l'isolation des transactions, ce qui veut dire qu'on peut être plusieurs à modifier la base en même temps et chacun ne voit que ses modifs, tant que ce n'est pas "commité". La fragmentation sera d'autant plus forte qu'il y aura des mise à jour (update), bien entendu si on fait surtout des select, la fragmentation sera faible. Je ne sais pas s'il est forcément nécessaire de faire des vacuum souvent, il faudrait mesurer l'impact sur les performances.