From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, hlinnakangas(at)vmware(dot)com, noah(at)leadboat(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Performance Improvement by reducing WAL for Update Operation |
Date: | 2013-01-04 14:33:56 |
Message-ID: | CA+U5nMLNvgMrdRB4qCxR4O-+ruEL1oJGpjev_4fSwCg5=Xu4xQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4 January 2013 13:53, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
> On Friday, December 28, 2012 3:52 PM Simon Riggs wrote:
>> On 28 December 2012 08:07, Kyotaro HORIGUCHI
>> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>
>> > Hello, I saw this patch and confirmed that
>> >
>> > - Coding style looks good.
>> > - Appliable onto HEAD.
>> > - Some mis-codings are fixed.
>>
>> I've had a quick review of the patch to see how close we're getting.
>> The perf tests look to me like we're getting what we wanted from this
>> and I'm happy with the recovery performance trade-offs. Well done to
>> both author and testers.
>>
>>
>> * The compression algorithm depends completely upon new row length
>> savings. If the new row is short, it would seem easier to just skip
>> the checks and include it anyway. We can say if old and new vary in
>> length by > 50% of each other, just include new as-is, since the rows
>> very clearly differ in a big way.
>
>> Also, if tuple is same length as
>> before, can we compare the whole tuple at once to save doing
>> per-column checks?
>
> If we have to do whole tuple comparison then storing of changed parts might
> need to be
> be done in a byte-by-byte way rather then at column offset boundaries.
> This might not be possible with current algorithm as it stores in WAL
> information column-by-column and decrypts also in similar way.
OK, please explain in comments.
>> The internal docs are completely absent. We need at least a whole page of
> descriptive > comment, discussing trade-offs and design decisions.
>
> Currently I have planned to put it transam/README, as most of WAL
> description is present there.
But also in comments for each major function.
Thanks
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | 孟庆钟 | 2013-01-04 16:13:27 | A very small typo in the comment |
Previous Message | Amit Kapila | 2013-01-04 13:53:58 | Re: Performance Improvement by reducing WAL for Update Operation |