Re: Filesystem Direct I/O and WAL sync option

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Dimitri" <dimitrik(dot)fr(at)gmail(dot)com>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "PostgreSQL Performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Filesystem Direct I/O and WAL sync option
Date: 2007-07-04 10:45:01
Message-ID: 87wsxgcus2.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


"Dimitri" <dimitrik(dot)fr(at)gmail(dot)com> writes:

> Yes Gregory, that's why I'm asking, because from 1800 transactions/sec
> I'm jumping to 2800 transactions/sec! and it's more than important
> performance level increase :))

wow. That's kind of suspicious though. Does the new configuration take
advantage of the lack of the filesystem cache by increasing the size of
shared_buffers? Even then I wouldn't expect such a big boost unless you got
very lucky with the size of your working set compared to the two sizes of
shared_buffers.

It seems likely that somehow this change is not providing the same guarantees
as fsync. Perhaps fsync is actually implementing IDE write barriers and the
sync mode is just flushing buffers to the hard drive cache and then returning.

What transaction rate do you get if you just have a single connection
streaming inserts in autocommit mode? What kind of transaction rate do you get
with both sync mode on and fsync=on in Postgres?

And did you say this with a battery backed cache? In theory fsync=on/off and
shouldn't make much difference at all with a battery backed cache. Stranger
and stranger.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Magnus Hagander 2007-07-05 05:15:04 Re: PostgreSQL Configuration Tool for Dummies
Previous Message Dimitri 2007-07-04 10:26:10 Re: Filesystem Direct I/O and WAL sync option