Re: [WIP] Performance Improvement by reducing WAL for Update Operation

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Heikki Linnakangas'" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "'Bruce Momjian'" <bruce(at)momjian(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Date: 2012-08-06 11:30:32
Message-ID: 002b01cd73c6$e48da7a0$ada8f6e0$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: Heikki Linnakangas [mailto:heikki(dot)linnakangas(at)enterprisedb(dot)com]
Sent: Monday, August 06, 2012 2:32 PM
To: Amit Kapila
Cc: 'Bruce Momjian'; pgsql-hackers(at)postgresql(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2012-08-06 11:48:32 Re: several problems in pg_receivexlog
Previous Message Magnus Hagander 2012-08-06 09:53:19 Re: postgres 9 bind address for replication