Re: [WIP] Performance Improvement by reducing WAL for Update Operation - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Date
Msg-id 501F8815.5090601@enterprisedb.com
Whole thread Raw
In response to Re: [WIP] Performance Improvement by reducing WAL for Update Operation  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: [WIP] Performance Improvement by reducing WAL for Update Operation
List pgsql-hackers
On 06.08.2012 06:10, Amit Kapila wrote:
> Currently the solution for fixed length columns cannot handle the case of
> variable length columns and NULLS. The reason is for fixed length columns
> there is no need of diff technology between old and new tuple, however for
> other cases it will be required.
> For fixed length columns, if we just note the OFFSET, LENGTH, VALUE of
> changed columns of new tuple in WAL, it will be sufficient to do the replay
> of WAL. However to handle other cases we need to use diff mechanism.
>
> Can we do something like if the changed columns are fixed length and doesn't
> contain NULL's, then store [OFFSET, LENGTH, VALUE] format in WAL and for
> other cases store diff format.
>
> This has advantage that for Updates containing only fixed length columns
> don't have to pay penality of doing diff between new and old tuple. Also we
> can do the whole work in 2 parts, one for fixed length columns and second to
> handle other cases.

Let's keep it simple and use the same diff format for all tuples, at 
least for now. If it turns out that you can indeed get even more gain 
for fixed length tuples by something like that, then let's do that later 
as a separate patch.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: chinnaobi
Date:
Subject: Windows Streaming replication -- Windows 2008 servers
Next
From: Magnus Hagander
Date:
Subject: Re: postgres 9 bind address for replication