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

From Neil Conway
Subject Re: [HACKERS] Performance while loading data and indexing
Date
Msg-id 87vg4szco1.fsf@mailbox.samurai.com
Whole thread Raw
In response to Re: [HACKERS] Performance while loading data and indexing  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] Performance while loading data and indexing  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] Performance while loading data and indexing  (Greg Copeland <greg@CopelandConsulting.Net>)
Re: [HACKERS] Performance while loading data and indexing  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
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.

Cheers,

Neil

--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

pgsql-general by date:

Previous
From: Holger Marzen
Date:
Subject: Formatting numbers in psql?
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Performance while loading data and indexing