Re: [HACKERS] Performance while loading data and indexing

Hello!

On Thu, 26 Sep 2002, Bruce Momjian wrote:

> > I'm not really familiar with the reasoning behind ext2's reputation as
> > recovering poorly from crashes; if we fsync a WAL record to disk

On relatively big volumes ext2 recovery can end up in formatting the fs
under certain cirrumstances.;-)

> > > I assumed it was the double fsync for the normal and journal that
> > > made the journalling file systems slog.
> >
> > Well, a journalling file system would need to write a journal entry
> > and flush that to disk, even if fsync is disabled -- whereas without
> > fsync enabled, ext2 doesn't have to flush anything to disk. ISTM that
> > the performance advantage of ext2 over ext3 is should be even larger
> > when fsync is not enabled.
>
> Yes, it is still double-writing. I just thought that if that wasn't
> happening while the db was waiting for a commit that it wouldn't be too
> bad.
>
> Is it just me or do all the Linux file systems seem like they are
> lacking something when PostgreSQL is concerned? We just want a UFS-like
> file system on Linux and no one has it.

mount -o sync an ext2 volume on Linux - and you can get a "UFS-like" fs.:)
mount -o async an FFS volume on FreeBSD - and you can get boost in fs
performance.
Personally me always mount ext2 fs where Pg is living with sync option.
Fsync in pg is off (since 6.3), this way successfully pass thru a few
serious crashes on various systems (mostly on power problems).
If fsync is on in Pg, performance gets so-oh-oh-oh-oh slowly!=)
I just have done upgrade from 2.2 kernel on ext2 to ext3 capable 2.4 one
so I'm planning to do some benchmarking. Roughly saying w/o benchmarks,
the performance have been degraded in 2/3 proportion.
"But better safe then sorry".

--
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg(at)center-f1(dot)ru(dot)
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.