Index: doc/src/sgml/maintenance.sgml =================================================================== RCS file: /projects/cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v retrieving revision 1.56 diff -c -r1.56 maintenance.sgml *** doc/src/sgml/maintenance.sgml 18 Jun 2006 15:38:35 -0000 1.56 --- doc/src/sgml/maintenance.sgml 15 Jul 2006 02:21:25 -0000 *************** *** 7,48 **** maintenance ! There are a few routine maintenance chores that must be performed on ! a regular basis to keep a PostgreSQL ! server running smoothly. The tasks discussed here are repetitive ! in nature and can easily be automated using standard Unix tools such ! as cron scripts. But it is the database ! administrator's responsibility to set up appropriate scripts, and to ! check that they execute successfully. ! ! One obvious maintenance task is creation of backup copies of the data on a ! regular schedule. Without a recent backup, you have no chance of recovery ! after a catastrophe (disk failure, fire, mistakenly dropping a critical ! table, etc.). The backup and recovery mechanisms available in ! PostgreSQL are discussed at length in ! . ! The other main category of maintenance task is periodic vacuuming ! of the database. This activity is discussed in ! . ! Something else that might need periodic attention is log file management. This is discussed in . ! ! PostgreSQL is low-maintenance compared ! to some other database management systems. Nonetheless, ! appropriate attention to these tasks will go far towards ensuring a ! pleasant and productive experience with the system. ! Routine Vacuuming --- 7,46 ---- maintenance + + Routine maintenance + + ! PostgreSQL, like any database software, requires that certain tasks ! be performed regularly to achieve optimum performance. The tasks ! discussed here are required, but they ! are repetitive in nature and can easily be automated using standard ! Unix tools such as cron scripts. ! ! PostgreSQL is low-maintenance compared ! to other database management systems. It is also fairly easy, provided ! you read the documentation. ! There are three tasks that must be performed on ! a periodic basis. The first is backups. If you do not have a current backup ! and your system experiences a catastrophic failure, you will lose your data. ! You can read further about backups procedures in . ! The second is vacuum which is discussed in . ! The third is to update the planner statistics using the analyze command as ! discussed in . ! Another task that may need periodic attention is log file management. This is discussed in . ! Routine Vacuuming *************** *** 53,63 **** PostgreSQL's VACUUM command ! must be run on a regular basis for several reasons: ! To recover disk space occupied by updated or deleted rows. --- 51,61 ---- PostgreSQL's VACUUM command ! must be run on a regular basis for several reasons: ! To recover or reuse disk space occupied by updated or deleted rows. *************** *** 82,92 **** ! The standard form of VACUUM can run in parallel with ! normal database operations (SELECTs, INSERTs, UPDATEs, DELETEs, but not ! changes to table definitions). ! Beginning in PostgreSQL 8.0, there are ! configuration parameters that can be adjusted to further reduce the performance impact of background vacuuming. See . --- 80,91 ---- ! The standard form of VACUUM does not intefere with production ! database operations. Items such as SELECTS, INSERTS, UPDATES and DELETES ! will continue to function as normal, though you will not be able to modify the ! definition (Such as ALTER TABLE ADD COLUMN) of a table while it is being vacuumed. ! The release of PostgreSQL 8.0, introduced new ! configuration parameters to further reduce the potentially negative performance impact of background vacuuming. See . *************** *** 187,195 **** ! If you have a table whose contents are deleted on a periodic ! basis, consider doing it with TRUNCATE rather ! than using DELETE followed by VACUUM. TRUNCATE removes the entire content of the table immediately, without requiring a subsequent VACUUM or VACUUM --- 186,194 ---- ! If you have a table whose entire contents are deleted on a periodic ! basis, consider doing it with the TRUNCATE rather ! than using the DELETE followed by VACUUM. TRUNCATE removes the entire content of the table immediately, without requiring a subsequent VACUUM or VACUUM