<Oops, wrong "From" again, resent>
I measured it in a different number of cases, both on SSDs and spinning rust. I just reproduced it with: postgres-ckpt14 \ -D /srv/temp/pgdev-dev-800/ \ -c maintenance_work_mem=2GB \ -c fsync=on \ -c synchronous_commit=off \ -c shared_buffers=2GB \ -c wal_level=hot_standby \ -c max_wal_senders=10 \ -c max_wal_size=100GB \ -c checkpoint_timeout=30s Using a fresh cluster each time (copied from a "template" to save time) and using pgbench -M prepared -c 16 -j 16 -T 300 -P 1
I must say that I have not succeeded in reproducing any significant regression up to now on an HDD. I'm running some more tests again because I had left out some options above that I thought were non essential.
I have deep problems with the 30-second checkpoint tests: basically the checkpoints take much more than 30 seconds to complete, the system is not stable, the 300 seconds runs last more than 900 seconds because the clients are stuck a long time. The overall behavior is appaling as most of the time is spent in IO panic at 0 tps.
Also, the performance level is around 160 tps on HDDs, which make sense to me for a 7200 rpm HDD capable of about x00 random writes per second. It seems to me that you reported much better performance on HDD, but I cannot really see how this would be possible if data are indeed writen to disk. Any idea?
Also, what is the very precise postgres version & patch used in your tests on HDDs?
both before/after patch are higher) if I disable full_page_writes, thereby eliminating a lot of other IO.
Maybe this is an explanation.... -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
