PostgreSQL 9.2.2 sur Windows 7 64 bits.
Le paramètre log_statementdu postgresql.conffichier spécifie les instructions à consigner (aucune, DDL, modification des données ou toutes). Dans quelle mesure le réglage log_statement = 'all'dégrade-t-il les performances? J'ai lu que cela réduit considérablement les performances, mais ces affirmations proviennent d'articles plus anciens, alors à quel niveau de perte de performances dois-je m'attendre par rapport à log_statement = 'none'?
Réponses:
Comme presque tout le reste, cela dépend de votre matériel, de votre configuration et de votre charge de travail.
Si vous exécutez quelques relevés coûteux, cela ne fera guère de différence; si vous exécutez beaucoup de minuscules instructions simples, cela fera plus de différence.
Si vos journaux se trouvent sur le même système de fichiers ou même sur le même disque que la base de données, la journalisation fera plus de différence que si les journaux sont stockés sur un disque distinct. Même si les journaux ne sont pas explicitement fsync()affichés et sont écrits de manière séquentielle, ils sont toujours en concurrence avec la base de données principale pour les E / S.
Plus important encore, certains systèmes de fichiers (ext3 en particulier) videront toutes les données lorsqu'un fichier est fsync()vide, de sorte que les écritures du journal deviennent plus proches des E / S aléatoires que des E / S séquentielles et ralentissent chaque validation. IIRC ce n'est pas un problème sur ext4 ou xfs.
Cela dépendra également de l'activation de la synchronisation des instructions, de la méthode de journalisation que vous utilisez, etc.
La meilleure option est de le comparer avec une simulation de votre charge de travail réelle et de voir.