Re: Performance Improvement by reducing WAL for Update Operation
От | Amit kapila |
---|---|
Тема | Re: Performance Improvement by reducing WAL for Update Operation |
Дата | |
Msg-id | 6C0B27F7206C9E4CA54AE035729E9C383BEAEF91@szxeml509-mbs обсуждение исходный текст |
Ответ на | Re: Performance Improvement by reducing WAL for Update Operation (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Performance Improvement by reducing WAL for Update Operation
|
Список | 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 по дате отправления: