ne pas mettre la cache en ecriture reduit les perf par ~10
l'integrité est conservé, sauf crash hard/soft
si tu a un serveur stable c'est plutot conseillé ( par ex: interbase l'active par defaut sous unix mais pas sous NT .. ils sont pas fou)
tu l'active pas si tu n'as pas d'onduleur ou un serveur à gros risque
enfin dire que ne pas l'activer c'est 'la porte' c'est tres pretencieux et montre bien que tu sais pas de quoi tu parle :
FSYNC (boolean)
If this option is on, the PostgreSQL backend will use the fsync() system call in several places to make sure that updates are physically written to disk and do not hang around in the kernel buffer cache. This increases the chance by a large amount that a database installation will still be usable after an operating system or hardware crash. (Crashes of the database server itself do not affect this consideration.)
However, this operation slows down PostgreSQL, because at all those points it has to block and wait for the operating system to flush the buffers. Without fsync, the operating system is allowed to do its best in buffering, sorting, and delaying writes, which can make for a considerable performance increase. However, if the system crashes, the results of the last few committed transactions may be lost in part or whole; in the worst case, unrecoverable data corruption may occur.
This option is the subject of an eternal debate in the PostgreSQL user and developer communities. Some always leave it off, some turn it off only for bulk loads, where there is a clear restart point if something goes wrong, some leave it on just to be on the safe side. Because it is the safe side, on is also the default. If you trust your operating system, your hardware, and your utility company (or better your UPS), you might want to disable fsync.
It should be noted that the performance penalty from doing fsyncs is considerably less in PostgreSQL version 7.1 than it was in prior releases. If you previously suppressed fsyncs because of performance problems, you may wish to reconsider your choice.
en gros je prend le risque de revenir a un backup d'au max vieux d'une heure si j'ai un crash HARD vraiment mechant pendant une ecriture
et je gange ~10x de perf en ecriture en contrepartie.
Ce n'est pas un choix idiot, juste savoir etudier un risque.
[^] # Re: indexes corrompus ?
Posté par vrm (site web personnel) . En réponse à la dépêche Sortie du SGBD Firebird en version 1.0 finale. Évalué à 4.
l'integrité est conservé, sauf crash hard/soft
si tu a un serveur stable c'est plutot conseillé ( par ex: interbase l'active par defaut sous unix mais pas sous NT .. ils sont pas fou)
tu l'active pas si tu n'as pas d'onduleur ou un serveur à gros risque
enfin dire que ne pas l'activer c'est 'la porte' c'est tres pretencieux et montre bien que tu sais pas de quoi tu parle :
FSYNC (boolean)
If this option is on, the PostgreSQL backend will use the fsync() system call in several places to make sure that updates are physically written to disk and do not hang around in the kernel buffer cache. This increases the chance by a large amount that a database installation will still be usable after an operating system or hardware crash. (Crashes of the database server itself do not affect this consideration.)
However, this operation slows down PostgreSQL, because at all those points it has to block and wait for the operating system to flush the buffers. Without fsync, the operating system is allowed to do its best in buffering, sorting, and delaying writes, which can make for a considerable performance increase. However, if the system crashes, the results of the last few committed transactions may be lost in part or whole; in the worst case, unrecoverable data corruption may occur.
This option is the subject of an eternal debate in the PostgreSQL user and developer communities. Some always leave it off, some turn it off only for bulk loads, where there is a clear restart point if something goes wrong, some leave it on just to be on the safe side. Because it is the safe side, on is also the default. If you trust your operating system, your hardware, and your utility company (or better your UPS), you might want to disable fsync.
It should be noted that the performance penalty from doing fsyncs is considerably less in PostgreSQL version 7.1 than it was in prior releases. If you previously suppressed fsyncs because of performance problems, you may wish to reconsider your choice.
en gros je prend le risque de revenir a un backup d'au max vieux d'une heure si j'ai un crash HARD vraiment mechant pendant une ecriture
et je gange ~10x de perf en ecriture en contrepartie.
Ce n'est pas un choix idiot, juste savoir etudier un risque.