From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Results of testing WAL |
Date: | 2000-11-10 03:44:01 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D316B@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I've run some tests with 7.1 + WAL & 7.0.2
Setup: 5 tables (i int, t text), 100000 records in each table,
sizeof(t column) is rand(256), indices on i column for all tables.
-B 16384 -A 0 (+ --wal_buffers=256 in 7.1)
System: SUN Ultra 10, 512M RAM, 1 (fast) IDE disk
Test: 5 clients simultaneously performed
UPDATE tableN SET t = '...rand(256) chars...' WHERE i = ...rand(100000)...;
Each UPDATE was in separate transaction, client N changed tableN only,
each client made 1000 transactions.
Results: 5000 transactions took ~60 sec in 7.1, ~550 sec in 7.0.2 with fsync
and ~60 sec without fsync.
So, seems that WAL added not just complexity to system -:)
I'm going to commit redo for sequences tomorrow evening and
#define XLOG by default after this (initdb will be required).
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-11-10 03:50:37 | Re: Tip of current tree: Seg fault in query |
Previous Message | Tom Lane | 2000-11-10 03:42:10 | Re: 7.0.2 dies when connection dropped mid-transaction |