Re: Performance Improvement by reducing WAL for Update Operation
От | Amit Kapila |
---|---|
Тема | Re: Performance Improvement by reducing WAL for Update Operation |
Дата | |
Msg-id | 002c01cdfefa$d0305540$7090ffc0$@kapila@huawei.com обсуждение исходный текст |
Ответ на | Re: Performance Improvement by reducing WAL for Update Operation (Amit Kapila <amit.kapila@huawei.com>) |
Ответы |
Re: Performance Improvement by reducing WAL for Update Operation
|
Список | pgsql-hackers |
On Tuesday, January 29, 2013 7:42 PM Amit Kapila wrote: > On Tuesday, January 29, 2013 3:53 PM Heikki Linnakangas wrote: > > On 29.01.2013 11:58, Amit Kapila wrote: > > > Can there be another way with which current patch code can be made > > better, > > > so that we don't need to change the encoding approach, as I am > having > > > feeling that this might not be performance wise equally good. > > > > The point is that I don't want to heap_delta_encode() to know the > > internals of pglz compression. You could probably make my patch more > > like yours in behavior by also passing an array of offsets in the new > > tuple to check, and only checking for matches as those offsets. > > I think it makes sense, because if we have offsets of both new and old > tuple, we > can internally use memcmp to compare columns and use same algorithm for > encoding. > I will change the patch according to this suggestion. I have modified the patch as per above suggestion. Apart from passing new and old tuple offsets, I have passed bitmaplength also, as we need to copy the bitmap of new tuple as it is into Encoded WAL Tuple. Please see if such API design is okay? I shall update the README and send the performance/WAL Reduction data for modified patch tomorrow. With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: