Re: HEAD seems to generate larger WAL regarding GIN index
От | Heikki Linnakangas |
---|---|
Тема | Re: HEAD seems to generate larger WAL regarding GIN index |
Дата | |
Msg-id | 53306DEA.8070803@vmware.com обсуждение исходный текст |
Ответ на | Re: HEAD seems to generate larger WAL regarding GIN index (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
I came up with the attached patch, to reduce the WAL volume of GIN insertions. It become fairly large, but I guess that's not too surprising as the old WAL-logging method was basically to dump the whole page to WAL record. This is now a lot more fine-grained and smarter. I separated constructing the WAL record from copying the changes back to the disk page, which IMHO is a readability improvement even though it's more code. There are two parts to this patch: * leafRepackItems has been rewritten. The previous coding basically searched for the first modified item, and decoded and re-encoded everything on the page that after that. Now it tries harder to avoid re-encoding segments that are still reasonably sized (between 128 and 384 bytes, with the target for new segments being 256 bytes). This ought to make random updates faster as a bonus, but I didn't performance test that. * Track more carefully which segments on the page have been modified. The in-memory structure used to manipulate a page now keeps an action code for each segment, indicating if the segment is completely new, deleted, or replaced with new content, or if just some new items have been added to it. These same actions are WAL-logged, and replayed in the redo routine. This brings the WAL volume back to the same ballpark as 9.3. Or better, depending on the operation. Fujii, Alexander, how does this look to you? - Heikki
Вложения
В списке pgsql-hackers по дате отправления: