Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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                        |
  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


pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group