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" <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:53:47 |
Message-ID: | CA+U5nM+RTojWTwG0CeWJ16=-GG9wUdJ+BaRLJwxmn7ZrnFCCZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11 January 2013 18:11, Amit kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>> 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.
Another patch is going through next CF related to reassembling changes
from WAL records.
To do that efficiently, we would want to store a bitmap showing which
columns had changed in each update. Would that be an easy addition, or
is that blocked by some aspect of the current design?
The idea would be that we could re-construct an UPDATE statement that
would perform exactly the same change, yet without needing to refer to
a base tuple.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-01-11 19:01:40 | Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) |
Previous Message | Tom Lane | 2013-01-11 18:39:09 | Re: [Pgbuildfarm-members] Version 4.10 of buildfarm client released. |