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

From Amit Kapila
Subject Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Date
Msg-id 002b01cd73c6$e48da7a0$ada8f6e0$@kapila@huawei.com
Whole thread Raw
In response to Re: [WIP] Performance Improvement by reducing WAL for Update Operation  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
From: Heikki Linnakangas [mailto:heikki.linnakangas@enterprisedb.com] 
Sent: Monday, August 06, 2012 2:32 PM
To: Amit Kapila
Cc: 'Bruce Momjian'; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [WIP] Performance Improvement by reducing WAL for
Update Operation
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.

Okay, I shall first try to design and implement the same format for all
tuples
and discuss the results of same with community.

With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: postgres 9 bind address for replication
Next
From: Magnus Hagander
Date:
Subject: Re: several problems in pg_receivexlog