Hi, Tom,
Thanks for the reply.
a) The tests consists of ten thousands very small transactions, which are
not grouped, that is why so slow with compare to set fsync off.
b) we are using Solaris 10 on a SUN Fire 240 SPARC machine with a latest
postgresql release (8.1.3)
c) wal_sync_method is set to 'open_datasync', which is fastest among the
four, right?
d) wal_buffers set to 32
Looks like, if we have to set fsync be true, we need to modify our
application.
Thanks and regards,
Guoping
-----Original Message-----
From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org]On Behalf Of Tom Lane
Sent: 2006Äê4ÔÂ28ÈÕ 0:53
To: guoping.zhang@nec.com.au
Cc: pgsql-performance@postgresql.org; Guoping Zhang (E-mail)
Subject: Re: [PERFORM] how unsafe (or worst scenarios) when setting
fsync OFF for postgresql
"Guoping Zhang" <guoping.zhang@nec.com.au> writes:
> Our application has a strict speed requirement for DB operation. Our tests
> show that it takes about 10secs for the operation when setting fsync off,
> but takes about 70 seconds when setting fsync ON (with other WAL related
> parametered tuned).
I can't believe that a properly tuned application would have an fsync
penalty that large. Are you performing that "operation" as several
thousand small transactions, or some such? Try grouping the operations
into one (or at most a few) transactions. Also, what wal_buffers and
wal_sync_method settings are you using, and have you experimented with
alternatives? What sort of platform is this on? What PG version?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend