Hello,
First of all: many thanks Tom for pointed me out what I made wrong and
Jim for 'spikes'.
I made some new tests:
available at http://85.128.68.44
What have changed since last time:
- database engine - now it's 8.1.0
- number of clients - "-c 20 "
- number of transactions - "-t 1000"
Really seems that you have made EXCELLENT work. Performance increased
about 25% in 8.1.0.
I also made some changes related with bg_write and wal (according to Jim):
bg_writer_all_percent = 0.433
bg_writer_all_maxpages = 15
wal_buffers = 8192
However I still can see 'spikey' performance but not as much as before
changes. What can I do more to eliminate or smooth these spikes? I
tried to increase bg_writer_all_xxx parameters but.... spikes still
exists ;).
Regards,
Marcin
>This is pretty nearly an ideal example of how NOT to use pg_bench :-(
>
>In the first place, don't use a number of clients (-c) much exceeding
>the scale factor (-s). If you do, then almost all you are measuring is
>the effects of update contention. There are only scale-factor rows in
>the branches table, and every pgbench transaction wants to update one of
>the branches rows, so with -c 100 and -s 20 there are on average going
>to be 5 transactions simultaneously trying to modify the same branches
>row. 4 of them are going to be waiting. Does that really correspond
>to a real-world situation that you want to optimize?
>
>In the second place, you need a run length considerably longer than
>-t 100 to avoid getting swamped by noise of startup/shutdown overhead.
>I usually use at least -t 1000 if I want repeatable numbers.
>
>BTW, PG 8.1 will probably do better than 8.0 on multi-CPU hardware.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
>
>
