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

From Amit kapila
Subject Re: Performance Improvement by reducing WAL for Update Operation
Date
Msg-id 6C0B27F7206C9E4CA54AE035729E9C383BEAEF91@szxeml509-mbs
Whole thread Raw
In response to Re: Performance Improvement by reducing WAL for Update Operation  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Performance Improvement by reducing WAL for Update Operation
List pgsql-hackers
On Friday, January 11, 2013 9:27 PM Simon Riggs wrote:
On 11 January 2013 14:24, Amit Kapila <amit.kapila@huawei.com> wrote:

>> http://archives.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C3828
>> 52DE51@szxeml509-mbs
>
>> 1. However Heikki has pointed, it has some problems similar to for HOT
>> implementation and that is the reason we have done memcmp for HOT.
>> 2. Also we have found in initial readings that this doesn't have any
>> performance difference as compare to current Approach.

>OK, forget that idea.

>>> I've moved this to the next CF. I'm planning to review this one first.
>
>> Thank you.

> Just reviewing the patch now, making more sense with comments added.

>In heap_delta_encode() do we store which columns have changed?

Not the attribute bumberwise, but offsetwise it is stored.

> Do we store the whole new column value?

Yes, please refer else part of code

+         else
+         {
+             data_len = new_tup_off - change_off;
+             if ((bp + (2 * data_len)) - bstart >= result_max)
+                 return false;
+
+             /* Copy the modified column data to the output buffer if present */
+             pglz_out_add(ctrlp, ctrlb, ctrl, bp, data_len, dp);
+

With Regards,
Amit Kapila.


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [Pgbuildfarm-members] Version 4.10 of buildfarm client released.
Next
From: Amit kapila
Date:
Subject: Re: Performance Improvement by reducing WAL for Update Operation