Re: PostgreSQL is extremely slow on Windows

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>, "Vig, Sandor (G/FI-2)" <Sandor(dot)Vig(at)audi(dot)hu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL is extremely slow on Windows
Date: 2005-02-24 21:25:34
Message-ID: 200502242125.j1OLPYF14343@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Neil Conway wrote:
> Magnus Hagander wrote:
> > Yes, fsync=false is very good for bulk loading *IFF* you can live with
> > data loss in case you get a crash during load.
>
> It's not merely data loss -- you could encounter potentially
> unrecoverable database corruption.
>
> There is a TODO item about allowing the delaying of WAL writes. If we
> maintain the WAL invariant (that is, a WAL record describing a change
> must hit disk before the change itself does) but simply don't flush the
> WAL at transaction commit, we should be able to get better performance
> without the risk of database corruption (so we would need to keep pages
> modified by the committed transaction pinned in memory until the WAL has
> been flushed, which might be done on a periodic basis).
>
> Naturally, there is a risk of losing data in the period between
> transaction commit and syncing the WAL, but no risk of database
> corruption. This seems a reasonable approach to providing better
> performance for people who don't need the strict guarantees provided by
> fsync=true.

Right. Just for clarity, you might lose the last 5 seconds of
transactions, but all transactsions would be completely committed or
aborted in your datbase. Right now with fsync off you can get
transactions partially commited in your database, which is a serious
problem (think moving money from one account to another).

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Gaetano Mendola 2005-02-24 22:30:06 Re: is pg_autovacuum so effective ?
Previous Message John Arbash Meinel 2005-02-24 19:40:56 Re: Peformance Tuning Opterons/ Hard Disk Layout