Re: checkpointer continuous flushing

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: checkpointer continuous flushing
Date: 2016-01-16 08:06:44
Message-ID: alpine.DEB.2.10.1601160901170.18181@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Andres,

> Hello Tomas.

Ooops, sorry Andres, I mixed up the thread in my head so was not clear who
was asking the questions to whom.

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

I confirm that: nothing special but "relatime" on ext4 on my test host.

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

"found" -> "fond". I confirm this opinion. If you have BBU on you
disk/raid system probably playing with some of these options is safe,
though. Not the case with my basic hardware.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2016-01-16 09:01:25 Re: checkpointer continuous flushing
Previous Message Fabien COELHO 2016-01-16 07:52:32 Re: checkpointer continuous flushing