On Mon, Feb 27, 2012 at 4:03 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > So please use a scale factor that the hardware can cope with.
OK. I tested this out on Nate Boley's 32-core AMD machine, using scale factor 100 and scale factor 300. I initialized it with Simon's patch, which should have the effect of rendering the entire table unhinted and giving each row a different XID. I used my usual configuration settings for that machine, which are: shared_buffers = 8GB, maintenance_work_mem = 1GB, synchronous_commit = off, checkpoint_segments = 300, checkpoint_timeout = 15min, checkpoint_completion_target = 0.9, wal_writer_delay = 20ms. I did three runs on master, as of commit 9bf8603c7a9153cada7e32eb0cf7ac1feb1d3b56, and three runs with the clog_history_v4 patch applied. The command to initialize the database was: ~/install/clog-contention/bin/pgbench -i -I -s $scale The command to run the test was: ~/install/clog-contention/bin/pgbench -l -T 1800 -c 32 -j 32 -n Executive Summary: The patch makes things way slower at scale factor 300, and possibly slightly slower at scale factor 100. Detailed Results: resultslp.clog_history_v4.32.100.1800:tps = 14286.049637 (including connections establishing) resultslp.clog_history_v4.32.100.1800:tps = 13532.814984 (including connections establishing) resultslp.clog_history_v4.32.100.1800:tps = 13972.987301 (including connections establishing) resultslp.clog_history_v4.32.300.1800:tps = 5061.650470 (including connections establishing) resultslp.clog_history_v4.32.300.1800:tps = 4871.126457 (including connections establishing) resultslp.clog_history_v4.32.300.1800:tps = 5861.124177 (including connections establishing) resultslp.master.32.100.1800:tps = 13420.777222 (including connections establishing) resultslp.master.32.100.1800:tps = 14912.336257 (including connections establishing) resultslp.master.32.100.1800:tps = 14505.718977 (including connections establishing) resultslp.master.32.300.1800:tps = 14766.984548 (including connections establishing) resultslp.master.32.300.1800:tps = 14783.026190 (including connections establishing) resultslp.master.32.300.1800:tps = 14567.504887 (including connections establishing) I don't know whether this is just a bug or whether there's some more fundamental problem with the approach. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers