Thread: Results of testing WAL
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
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes: > 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 -:) Sounds great! > I'm going to commit redo for sequences tomorrow evening and > #define XLOG by default after this (initdb will be required). I suggest bumping the catversion.h number when you #define XLOG, so that people won't be able to accidentally start an old postmaster with new DB or vice versa. regards, tom lane
> > I'm going to commit redo for sequences tomorrow evening and > > #define XLOG by default after this (initdb will be required). > > I suggest bumping the catversion.h number when you #define XLOG, > so that people won't be able to accidentally start an old postmaster > with new DB or vice versa. Thanks! Vadim
> > 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 -:) > > Wow, this sounds fantastic :-) > I see my concerns where not justified. Let's see first how justified are my hopes that WAL code are bug free -:) Vadim