Re: checkpointer continuous flushing

<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.