From: | Amit kapila <amit(dot)kapila(at)huawei(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "hlinnakangas(at)vmware(dot)com" <hlinnakangas(at)vmware(dot)com>, "noah(at)leadboat(dot)com" <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance Improvement by reducing WAL for Update Operation |
Date: | 2013-01-11 18:11:11 |
Message-ID: | 6C0B27F7206C9E4CA54AE035729E9C383BEAFFE7@szxeml509-mbs |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Friday, January 11, 2013 11:09 PM Simon Riggs wrote:
On 11 January 2013 17:08, Amit kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>>> Just reviewing the patch now, making more sense with comments added.
>
>>>In heap_delta_encode() do we store which columns have changed?
>
>> Not the attribute bumberwise, but offsetwise it is stored.
> (Does that mean "numberwise"??)
Yes.
> Can we identify which columns have changed? i.e. 1st, 3rd and 12th columns?
As per current algorithm, we can't as it is based on offsets.
What I mean to say is that the basic idea to reconstruct tuple during recovery
is copy data from old tuple offset-wise (offsets stored in encoded tuple) and use new data (modified column data)
from encoded tuple directly. So we don't need exact column numbers.
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit kapila | 2013-01-11 18:15:10 | Re: Performance Improvement by reducing WAL for Update Operation |
Previous Message | Simon Riggs | 2013-01-11 17:42:09 | Re: Performance Improvement by reducing WAL for Update Operation |