Re: [PERFORM] [HACKERS] fsync vs open_sync
On Tue, 2004-08-10 at 10:18 -0700, Josh Berkus wrote: Guys, just so you know: OSDL did some testing and found Ext3 to be perhaps the worst FS for PostgreSQL -- although this testing was with the default options. Ext3 involved an almost 40% write performance penalty compared with Ext2, whereas the penalty for ReiserFS and JFS was less than 10%. This concurs with my personal experience. Yes, I have been wondering about the relative trade offs between underlying file systems and pgsql. For metadata journalled filesystems, wouldn't fdatasync be a better option, since the fs is journalling the metadata anyway? With its default settings (data=ordered), ext3 is making a guaranty that after a crash, the filesystem will not only be in a consistent state, but the files (including the WAL) will not contain garbage, though their contents may not be the latest. With reiserfs and JFS, files can contain garbage. (I'm not sure what the implications of all this for pgsql are.) And wouldn't the following comparisons with ext3 be more interesting: ext3,data=writeback,fdatasync vs Other_Journalled_FS,fdatasync or ext3,data=journal,open_sync vs Other_Journalled_FS,fdatasync Just wondering. -Steve ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PERFORM] postgresql 8.0 beta - fail to collect statsistic
If IPv6 doesn't work, shouldn't it fall back to IPv4, or check IPv4 first, or something? Just wondering. -Steve Bergman ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PERFORM] fsync vs open_sync
On Sat, 2004-09-04 at 23:47 -0400, Christopher Browne wrote: The world rejoiced as [EMAIL PROTECTED] (Merlin Moncure) wrote: Ok, you were right. I made some tests and NTFS is just not very good in the general case. I've seen some benchmarks for Reiser4 that are just amazing. Reiser4 has been sounding real interesting. Are these independent benchmarks, or the benchmarketing at namesys.com? Note that the APPEND, MODIFY, and OVERWRITE phases have been turned off on the mongo tests and the other tests have been set to a lexical (non default for mongo) mode. I've done some mongo benchmarking myself and reiser4 loses to ext3 (data=ordered) in the excluded tests. APPEND phase performance is absolutely *horrible*. So they just turned off the phases in which reiser4 lost and published the remaining results as proof that resier4 is the fastest filesystem. See: http://marc.theaimsgroup.com/?l=reiserfsm=109363302000856 -Steve Bergman ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PERFORM] Optimizing for writes. Data integrity not critical
Hi, I am using postgresql in small (almost trivial) application in which I pull some data out of a Cobol C/ISAM file and write it into a pgsl table. My users can then use the data however they want by interfacing to the data from OpenOffice.org. The amount of data written is about 60MB and takes a few minutes on a 1200Mhz Athlon with a single 60MB IDE drive running Fedora Core 3 with pgsql 7.4.7. I'd like to speed up the DB writes a bit if possible. Data integrity is not at all critical as the database gets dropped, created, and populated immediately before each use. Filesystem is ext3, data=ordered and I need to keep it that way as there is other data in the filesystem that I do care about. I have not done any tuning in the config file yet, and was wondering what things would likely speed up writes in this situation. I'm doing the writes individually. Is there a better way? Combining them all into a transaction or something? Thanks, Steve Bergman ---(end of broadcast)--- TIP 8: explain analyze is your friend
