Re: [WIP] Performance Improvement by reducing WAL for Update Operation
От | Amit Kapila |
---|---|
Тема | Re: [WIP] Performance Improvement by reducing WAL for Update Operation |
Дата | |
Msg-id | 002b01cd73c6$e48da7a0$ada8f6e0$@kapila@huawei.com обсуждение исходный текст |
Ответ на | Re: [WIP] Performance Improvement by reducing WAL for Update Operation (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | 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 по дате отправления: