Skip site navigation (1) Skip section navigation (2)

Re: Performance Improvement by reducing WAL for Update Operation

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: "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-12 10:15:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
>   log_heap_update.
>   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
any purpose.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 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 ZoltanDate: 2013-01-12 07:42:54
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group