Re: WAL Re-Writes

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
Cc: pgsql-hackers <Pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL Re-Writes
Date: 2016-01-28 04:24:17
Message-ID: CAA4eK1+A+0RMEynvhTRbLfeRem64FMcSM=8zq+_pWjN0P7gW5g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 28, 2016 at 1:34 AM, james <james(at)mansionfamily(dot)plus(dot)com> wrote:

> On 27/01/2016 13:30, Amit Kapila wrote:
>
>>
>> Thoughts?
>>
>> Are the decreases observed with SSD as well as spinning rust?
>
>
The test is done with WAL on SSD and data on spinning rust, but I
think the results should be similar if we would have done it
otherwise as well. Having said that, I think still it is worth-while to
test it that way and I will do it.

> I might imagine that decreasing the wear would be advantageous,

Yes.

> especially if the performance decrease is less with low read latency.
>
>
Let me clarify again here that with 4096 bytes chunk size, there is
no performance decrease observed and rather there is a performance
increase though relatively-small (1~5%) and there is a reduction of ~35%
disk writes. Only if we do exact writes or write with smaller chunk size
like (512 or 1024 bytes, basically lesser than OS block size), then we can
see performance decrease mainly for wal_level < ARCHIVE, but then
writes are much more smaller. I would also like to mention that what we
call reduction in disk writes, this is the 7th column in stat file [1]
(write sectors - number of sectors written, for details you can refer
documentation of stat file [1]).

[1] - https://www.kernel.org/doc/Documentation/block/stat.txt

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2016-01-28 04:47:15 Re: Fwd: Core dump with nested CREATE TEMP TABLE
Previous Message Corey Huinker 2016-01-28 04:19:02 Re: [POC] FETCH limited by bytes.