Simon,
I am seeing a reasonably reproducible performance boost after applying your patch (I'm not sure if that was one of the main objectives, but it certainly is nice).
I *was* seeing a noticeable decrease between 7.4.6 and 8.0.0RC1 running pgbench. However, after applying your patch, 8.0 is pretty much back to being the same.
Now I know pgbench is ..err... not always the most reliable for this sort of thing, so I am interested if this seems like a reasonable sort of thing to be noticing (and also if anyone else has noticed the decrement)?
(The attached brief results are for Linux x86, but I can see a similar performance decrement 7.4.6->8.0.0RC1 on FreeBSD 5.3 x86)
regards
Mark Simon Riggs wrote:
Hmm...must confess that my only plan is: i) discover dynamic behaviour of bgwriter ii) fix any bugs or wierdness as quickly as possible iii) try to find a way to set the bgwriter defaults
System ------ P4 2.8Ghz 1G 1xSeagate Barracuda 40G Linux 2.6.9 glibc 2.3.3 gcc 3.4.2 Postgresql 7.4.6 | 8.0.0RC1
Test ---- Pgbench with scale factor = 200 Pg 7.4.6 -------- clients transactions tps 1 1000 65.1 2 1000 72.5 4 1000 69.2 8 1000 48.3 Pg 8.0.0RC1 ----------- clients transactions tps tps (new buff patch + settings) 1 1000 55.8 70.9 2 1000 68.3 77.9 4 1000 38.4 62.8 8 1000 29.4 38.1 (averages over 3 runs, database dropped and recreated after each set, with a checkpoint performed after each individual run) Parameters ---------- Non default postgresql.conf parameters: tcpip_socket = true [listen_addresses = "*"] max_connections = 100 shared_buffers = 10000 wal_buffers = 1024 checkpoint_segments = 10 effective_cache_size = 40000 random_page_cost = 0.8 bgwriter settings (used with patch only) bgwriter_delay = 200 bgwriter_percent = 2 bgwriter_maxpages = 100
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
