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

Re: Performance Improvement by reducing WAL for Update Operation

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-12 03:50:10
Message-ID: 6C0B27F7206C9E4CA54AE035729E9C383BEB00D5@szxeml509-mbs (view raw or flat)
Thread:
Lists: pgsql-hackers
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.
  

> 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.


With Regards,
Amit Kapila. 

In response to

Responses

pgsql-hackers by date

Next:From: Tory M BlueDate: 2013-01-12 05:49:21
Subject: Wide area replication postgres 9.1.6 slon 2.1.2 large table failure.
Previous:From: Josh BerkusDate: 2013-01-12 01:41:47
Subject: Re: AIX buildfarm member

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