Re: checkpointer continuous flushing

> Hi Fabien,

Hello Tomas.

> On 2016-01-11 14:45:16 +0100, Andres Freund wrote:
>> 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
>
> What kernel, filesystem and filesystem option did you measure with?

Andres did these measures, not me, so I do not know.

> I was/am using ext4, and it turns out that, when abling flushing, the
> results are hugely dependant on barriers=on/off, with the latter making
> flushing rather advantageous. Additionally data=ordered/writeback makes
> measureable difference too.

These are very interesting tests, I'm looking forward to have a look at 
the results.

The fact that these options change performance is expected. Personnaly the 
test I submitted on the thread used ext4 with default mount options plus 
"relatime".

If I had a choice, I would tend to take the safest options, because the 
point of a database is to keep data safe. That's why I'm not found of the 
"synchronous_commit=off" chosen above.

> Reading kernel sources trying to understand some more of the performance
> impact.

Wow!

-- 
Fabien.