From: | Phuong Ma <pma(at)commandprompt(dot)com> |
---|---|
To: | Postgres-general <pgsql-general(at)postgresql(dot)org> |
Subject: | WAL article |
Date: | 2001-06-07 23:07:04 |
Message-ID: | 3B200918.973AACFB@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello everyon,
I'm writing a section about Write Ahead Logging. I would appreciate
it if you can read this and give me some feedback. Such as: Is it
correct? Clear? Precise?
If there is anything wrong, please email me.
Thank you ALL.
--------------------------------------
Write Ahead Logging (WAL)
This Postgres feature enables database administrators to increase
database performance. It does this through writing log records of all
modifications before the commit is performed. When the commit occurs or
when a checkpoint is reached, the log files are then written to
permanent data. Therefore, the file modified does not change until it
is logged.
The advantage of using Write Ahead Logging is when a crash occurs
before the commit is executed, the log will still exist and the changes
are not lost. The modifications can then be retrieved from the log
files. A user can continue to work from the point they were at before
the crash occurred.
WAL consists of the following main elements:
Segments
These memory buffer segments are files which are 16MB in size.
When the usage level reaches 75% of the segment, then a new segment is
then created. To create an exact number of segments, modify the
WAL_FILES parameters.
log files
These files contain an ordered list of REDO/UNDO actions. They
also contain the new and old data. These log files are written
consecutively, one after the other. This causes the WAL to access the
log in sequential order, making the WAL process even faster.
checkpoints
These are points in a sequence of transactions. When these
points are reached, the log files created before these points are
ensured to have been committed.
WAL enables the system to avoid the process of writing to disk on every
transaction commit. There is a decrease in the number of disk writes
happening, causing the disk access to speed up.
From | Date | Subject | |
---|---|---|---|
Next Message | Grant | 2001-06-07 23:11:21 | very big problem with NULL |
Previous Message | Dennis | 2001-06-07 23:06:48 | Re: Foreign Key Problem |