On 12 January 2013 03:50, Amit kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
> On Saturday, January 12, 2013 12:23 AM Simon Riggs wrote:
> 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?
> I don't think it should be a problem, as it can go in current way of WAL tuple construction as
> we do in this patch when old and new buf are different. This differentiation is done in
> IMO, for now we can avoid this optimization (way we have done incase updated tuple is not on same page)
> for the bitmap storing patch and later we can evaluate if we can do this optimization for
> the feature of that patch.
Yes, we can simply disable this feature. But that is just bad planning
and we should give some thought to having new features play nicely
I would like to work out how to modify this so it can work with wal
decoding enabled. I know we can do this, I want to look at how,
because we know we're going to do it.
>> 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.
> I understood, that such a functionality would be needed by logical replication.
Yes, though the features being added are to allow decoding of WAL for
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2013-01-12 10:26:37|
|Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree
mulation (was xlogreader-v4)|
|Previous:||From: Boszormenyi Zoltan||Date: 2013-01-12 07:42:54|
|Subject: Re: Proposal for Allow postgresql.conf values to be changed
via SQL [review]|