Commit 8d1c1d40 authored by Bruce Momjian's avatar Bruce Momjian

Update fsync FAQ item.

parent c86fac27
Frequently Asked Questions (FAQ) for PostgreSQL Frequently Asked Questions (FAQ) for PostgreSQL
Last updated: Mon Jun 10 16:44:55 EDT 2002 Last updated: Mon Jun 10 22:22:31 EDT 2002
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us) Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
...@@ -323,29 +323,16 @@ ...@@ -323,29 +323,16 @@
reduce lock contention. reduce lock contention.
Performance Performance
PostgreSQL runs in two modes. Normal fsync mode flushes every PostgreSQL has performance similar to other commercial and open
completed transaction to disk, guaranteeing that if the OS source databases. it is faster for some things, slower for
crashes or loses power in the next few seconds, all your data others.
is safely stored on disk. In this mode, we are slower than most
commercial databases, partly because few of them do such
conservative flushing to disk in their default modes. In
no-fsync mode, we are usually faster than commercial databases,
though in this mode, an OS crash could cause data corruption.
We are working to provide an intermediate mode that suffers
less performance overhead than full fsync mode, and will allow
data integrity within 30 seconds of an OS crash.
In comparison to MySQL or leaner database systems, we are In comparison to MySQL or leaner database systems, we are
slower on inserts/updates because we have transaction overhead. slower on inserts/updates because we have transaction overhead.
Of course, MySQL does not have any of the features mentioned in Of course, MySQL does not have any of the features mentioned in
the Features section above. We are built for flexibility and the Features section above. We are built for reliability and
features, though we continue to improve performance through features, though we continue to improve performance in every
profiling and source code analysis. There is an interesting Web release. There is an interesting Web page comparing PostgreSQL
page comparing PostgreSQL to MySQL at to MySQL at http://openacs.org/why-not-mysql.html
http://openacs.org/why-not-mysql.html
We handle each user connection by creating a Unix process.
Backend processes share data buffers and locking information.
With multiple CPUs, multiple backends can easily run on
different CPUs.
Reliability Reliability
We realize that a DBMS must be reliable, or it is worthless. We We realize that a DBMS must be reliable, or it is worthless. We
......
...@@ -14,7 +14,7 @@ ...@@ -14,7 +14,7 @@
alink="#0000ff"> alink="#0000ff">
<H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1> <H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1>
<P>Last updated: Mon Jun 10 16:44:55 EDT 2002</P> <P>Last updated: Mon Jun 10 22:22:31 EDT 2002</P>
<P>Current maintainer: Bruce Momjian (<A href= <P>Current maintainer: Bruce Momjian (<A href=
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR> "mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
...@@ -425,32 +425,20 @@ ...@@ -425,32 +425,20 @@
<DT><B>Performance</B></DT> <DT><B>Performance</B></DT>
<DD>PostgreSQL runs in two modes. Normal <I>fsync</I> mode <DD>PostgreSQL has performance similar to other commercial and
flushes every completed transaction to disk, guaranteeing that if open source databases. it is faster for some things, slower for
the OS crashes or loses power in the next few seconds, all your others.
data is safely stored on disk. In this mode, we are slower than
most commercial databases, partly because few of them do such
conservative flushing to disk in their default modes. In
<I>no-fsync</I> mode, we are usually faster than commercial
databases, though in this mode, an OS crash could cause data
corruption. We are working to provide an intermediate mode that
suffers less performance overhead than full fsync mode, and will
allow data integrity within 30 seconds of an OS crash.<BR>
<BR> <BR>
In comparison to MySQL or leaner database systems, we are slower In comparison to MySQL or leaner database systems, we are slower
on inserts/updates because we have transaction overhead. Of on inserts/updates because we have transaction overhead. Of
course, MySQL does not have any of the features mentioned in the course, MySQL does not have any of the features mentioned in the
<I>Features</I> section above. We are built for flexibility and <I>Features</I> section above. We are built for reliability and
features, though we continue to improve performance through features, though we continue to improve performance in every
profiling and source code analysis. There is an interesting Web release. There is an interesting Web page comparing PostgreSQL to
page comparing PostgreSQL to MySQL at <A href= MySQL at <A href= "http://openacs.org/why-not-mysql.html">
"http://openacs.org/why-not-mysql.html">http://openacs.org/why-not-mysql.html</A><BR>
http://openacs.org/why-not-mysql.html</A><BR>
<BR>
We handle each user connection by creating a Unix process.
Backend processes share data buffers and locking information.
With multiple CPUs, multiple backends can easily run on different
CPUs.<BR>
<BR> <BR>
</DD> </DD>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment