Hi, Tom Many thanks for quick replies and that helps a lot.
Just in case, anyone out there can recommend a good but cost effective battery-backed write cache SCSI for Solaris SPARC platform? How well does it work with UFS or newer ZFS for solaris? Cheers and regards, Guoping -----Original 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" <[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? You shouldn't assume that without testing. > Looks like, if we have to set fsync be true, we need to modify our > application. Yes, you should definitely look into batching your operations into larger transactions. On normal hardware you can't expect to commit transactions faster than one per disk revolution (unless they're coming from multiple clients, where there's a hope of ganging several parallel commits per revolution). Or buy a disk controller with battery-backed write cache and put your faith in that cache surviving a machine crash. But don't turn off fsync if you care about your data. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
