Bruce Momjian writes:
> 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).
It's worse than that. You can get a totally corrupted database. Things like
duplicated records (the bef
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
Neil Conway <[EMAIL PROTECTED]> writes:
> 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
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 writ
> > You can *never* get above 80 without using write cache,
> regardless of
> > your OS, if you have a single disk.
>
> Why? Even with, say, a 15K RPM disk? Or the ability to
> fsync() multiple concurrently-committing transactions at once?
Uh. What I meant was a single *IDE* disk. Sorry. Been
> Hi,
>
> I changed fsync to false. It took 8 minutes to restore the
> full database.
> That is 26 times faster than before. :-/ (aprox. 200 tps)
> With background writer it took 12 minutes. :-(
That seems reasonable.
> The funny thing is, I had a VMWARE emulation on the same
> Windows mashi
Hi, Magnus & all,
Magnus Hagander schrieb:
> 20-30 transactionsi s about what you'll get on a single disk on Windows
> today.
> We have a patch in testing that will bring this up to about 80.
> You can *never* get above 80 without using write cache, regardless of
> your OS, if you have a single di
Tuesday, February 22, 2005 7:15 PM
To: Vig, Sandor (G/FI-2); pgsql-performance@postgresql.org
Subject: RE: [PERFORM] PostgreSQL is extremely slow on Windows
>I've downloaded the latest release (PostgreSQL 8.0) for windows.
>Installation was OK, but I have tried to restore a datab
Magnus Hagander wrote:
You can *never* get above 80 without using write cache, regardless of
your OS, if you have a single disk.
Why? Even with, say, a 15K RPM disk? Or the ability to fsync() multiple
concurrently-committing transactions at once?
-Neil
---(end of broadcast
>I've downloaded the latest release (PostgreSQL 8.0) for windows.
>Installation was OK, but I have tried to restore a database.
>It had more than ~100.000 records. Usually I use PostgreSQL
>under Linux, and it used to be done under 10 minutes.
>
>Under W2k und XP it took 3 hours(!) Why is it so sl
On Tue, 22 Feb 2005 16:00:59 +0100, Vig, Sandor (G/FI-2)
<[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> I've downloaded the latest release (PostgreSQL 8.0) for windows.
> Installation was OK, but I have tried to restore a database.
> It had more than ~100.000 records. Usually I use PostgreSQL
> under
11 matches
Mail list logo
