Hk, Guoping,
Guoping Zhang wrote:
> 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.
If those transactions are submitted by concurrent applications over
several simulataneous connections, playing with comm
vantage of battery backed write cache...
Regards,
Mikael
-Original Message-
From: Guoping Zhang [mailto:[EMAIL PROTECTED]
Sent: den 28 april 2006 07:35
To: Mikael Carneholm; pgsql-performance@postgresql.org
Cc: Guoping Zhang (E-mail)
Subject: RE: [PERFORM] how unsafe (or worst scena
Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 2006Äê4ÔÂ28ÈÕ 14:57
To: [EMAIL PROTECTED]
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&quo
erformance@postgresql.org; Guoping Zhang (E-mail)
Subject: Re: [PERFORM] how unsafe (or worst scenarios) when setting
fsync OFF for postgresql
Guoping,
On 4/27/06, Guoping Zhang <[EMAIL PROTECTED]> wrote:
> We have to looking at setting fsync OFF option for performance reason,
Did you try
"Guoping Zhang" <[EMAIL PROTECTED]> writes:
> But altering the commit_delay from 1 to 10, I observed that there is no
> time difference for the operation. Why is that? As our tests consists of
> 1 small transactions which completed in 66 seconds, that is, about 160
> transactions per second
n Riggs
Cc: [EMAIL PROTECTED]; pgsql-performance@postgresql.org; Guoping
Zhang (E-mail)
Subject: Re: [PERFORM] how unsafe (or worst scenarios) when setting
fsync
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2006-04-27 at 16:31 +1000, Guoping Zhang wrote:
>> Can we set fsync OFF fo
"Guoping Zhang" <[EMAIL PROTECTED]> writes:
> 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.
Yup.
> c) wal_sync_method is set to 'open_datasync', which is fastest among the
> four, right?
Well, is it? Y
Lane
Sent: 2006Äê4ÔÂ28ÈÕ 0:53
To: [EMAIL PROTECTED]
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" <[EMAIL PROTECTED]> writes:
> Our application has a st
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2006-04-27 at 16:31 +1000, Guoping Zhang wrote:
>> Can we set fsync OFF for the performance benefit, have the risk of only 5
>> minutes data loss or much worse?
> Thats up to you.
> fsync can be turned on and off, so you can make critical changes
"Guoping Zhang" <[EMAIL PROTECTED]> 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 ca
Guoping,
On 4/27/06, Guoping Zhang <[EMAIL PROTECTED]> wrote:
> We have to looking at setting fsync OFF option for performance reason,
Did you try the other wal sync methods (fdatasync in particular)? I
saw a few posts lately explaining how changing sync method can affect
performances in specific
Get a SCSI controller with a battery backed cache, and mount the disks
with data=writeback (if you use ext3). If you loose power in the middle
of a transaction, the battery will ensure that the write operation still
completes. With asynch writing setup like this, fsync operations will
return almost
On Thu, 2006-04-27 at 16:31 +1000, Guoping Zhang wrote:
> We have to looking at setting fsync OFF option for performance reason,
> our questions are
>
> a) if we set fsync OFF and anything (very low chance though) like OS
> crash, loss of power, or hardware fault happened, can postgresql rolls
13 matches
Mail list logo
