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