Re: [HACKERS] Performance while loading data and indexing - Mailing list pgsql-general

From Bruce Momjian
Subject Re: [HACKERS] Performance while loading data and indexing
Date
Msg-id 200209262107.g8QL7vN25965@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Performance while loading data and indexing  (Neil Conway <neilc@samurai.com>)
Responses Re: [HACKERS] Performance while loading data and indexing  (Yury Bokhoncovich <byg@center-f1.ru>)
List pgsql-general
Neil Conway wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Wow.  That leaves no good Linux file system alternatives.
> > PostgreSQL just wants an ordinary file system that has reliable
> > recovery from a crash.
>
> 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
> before we lose power, can't we recover reliably, even with ext2?
>
> > > > Also, though ext3 is slower, turning fsync off should make ext3
> > > > function similar to ext2.
> > >
> > > Why would that be?
> >
> > 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.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-general by date:

Previous
From: Neil Conway
Date:
Subject: Re: [HACKERS] Performance while loading data and indexing
Next
From: Greg Copeland
Date:
Subject: Re: [HACKERS] Performance while loading data and indexing