> I've run tests (with 50 .. 250 simult users) for some PG project
> of my company. 7.1 was 3 times faster than 7.0.3 (fsync) but near
> 3 times slower than 7.0.3 (nofsync). It was not the best day in
> my life - WAL looked like big bottleneck -:(
>
> But finally I've realized that this test makes ~3 FK insertions
> ... and FK insert means SELECT FOR UPDATE ... and this could
> reduce # of commits per fsync.
>
> So, I've run simple test (below) to check this. Seems that 7.1
> is faster than 7.0.3 (nofsync), and that SELECT FOR UPDATE in RI
> triggers is quite bad for performance.
>
> Please take this into account when comparing 7.1 with 7.0.3.
> Also, we should add new TODO item: implement dirty reads
> and use them in RI triggers.
>
> Vadim
I did some testings using contrib/pgbench (100k tuples, 32 concurrent
users) with 7.1 and 7.0.3. It seems 7.1 is 5 times faster than 7.0.3
with fsync, but 1.5 times slower than 7.0.3 without fsync.
So I modified access/transam/xlog.c to disable fsync() call at
all. Now I get nearly equal performance as 7.0.3 without fsync. It
seems the bottle neck is logging with fsync(). It might be interesting
moving data/pg_xlog to a separate disk drive and see how it performs
better.
BTW pgbench does PK insertions and updates, but does no FK things.
--
Tatsuo Ishii