j'avais à l'époque fait quelques comparatifs, sur une application qui travaille basiquement sur des tables clef/valeur. Oracle (sans tuning) et PostgreSQL (réglage en suivant le manuel) tenaient la charge jusqu'à 7000 trans/s. SQL Server 2005 (sans tuning) autour de 3000 et MySQL 5.0 (sans tuning) 2300 en InnoDb : sur un vieux Dell Poweredge 2900 (1x Xeon 5160, linux 64 bits) en RAID10 SAS.
Pour les question de "bloat" sur des tables de 200.000.000 de lignes, en faisant confiance uniquement à l'auto-vacuum, on perdait jusqu'à 5Go dans la table et 2Go dans les index, les "Bitmap Index Scan" de PostgreSQL passaient de quelques ms à plusieurs secondes.
Après, selon la doc et le forums, ça dépend du type d'utilisation, on peut tomber dans des cas qui accentuent le "bloat".
(aujourd'hui je vois plutôt des setup "low cost", certes pour des applications non critiques, avec une volumétrie raisonnable de 500Go sur du bête HP DL360 G6)
[^] # Re: question bête
Posté par let antibarbie = xp <- xp - 1 . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 4.
j'avais à l'époque fait quelques comparatifs, sur une application qui travaille basiquement sur des tables clef/valeur. Oracle (sans tuning) et PostgreSQL (réglage en suivant le manuel) tenaient la charge jusqu'à 7000 trans/s. SQL Server 2005 (sans tuning) autour de 3000 et MySQL 5.0 (sans tuning) 2300 en InnoDb : sur un vieux Dell Poweredge 2900 (1x Xeon 5160, linux 64 bits) en RAID10 SAS.
Pour les question de "bloat" sur des tables de 200.000.000 de lignes, en faisant confiance uniquement à l'auto-vacuum, on perdait jusqu'à 5Go dans la table et 2Go dans les index, les "Bitmap Index Scan" de PostgreSQL passaient de quelques ms à plusieurs secondes.
Après, selon la doc et le forums, ça dépend du type d'utilisation, on peut tomber dans des cas qui accentuent le "bloat".
(aujourd'hui je vois plutôt des setup "low cost", certes pour des applications non critiques, avec une volumétrie raisonnable de 500Go sur du bête HP DL360 G6)