
> Ok, I've made changes in xlog.c and run tests: 50 clients inserted
> (int4, text[1-256]) into 50 tables,
> -B 16384, -wal_buffers 256, -wal_files 0.
> 
> FSYNC:        257tps
> O_DSYNC:      333tps   
> 
> Just(?) 30% faster, -:(

First of all, if you ask me, that is one hell of an improvement :-)
It shows, that WAL write was actually the bottleneck in this particular case.
The bottleneck may now have shifted to some other resource.

It would probably also be good, to actually write more than one 
page with one call instead of the current "for (;XLByteLT...)" loop
in XLogWrite. The reasoning is, 1. that for each call to write, the OS
takes your timeslice away, allowing other backends to work, 
and thus reposition the disk head (for selects). 
and second measurements with tfsync.c:

zeu@a82101002:~> xlc -O2 tfsync.c -DINIT_WRITE -DUSE_ODSYNC -DBUFFERS=1 -o tfsync
zeu@a82101002:~> time tfsync
real    0m26.174s
user    0m0.040s
sys     0m2.920s
zeu@a82101002:~> xlc -O2 tfsync.c -DINIT_WRITE -DUSE_ODSYNC -DBUFFERS=8 -o tfsync
zeu@a82101002:~> time tfsync
real    0m8.950s
user    0m0.010s
sys     0m2.020s

Andreas

PS: to Tom, on AIX O_SYNC and O_DSYNC does not make a difference with tfsync.c,
both are comparable to your O_DSYNC measurements, maybe this is because of the 
jfs journal, where only one write to journal is necessary for all fs work (inode...).

Mon, 12 Mar 2001 16:25:28 +0100
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: AW: AW: AW: WAL does not recover gracefully from ou
	t-of -dis k-sp ace