Re: HEAD seems to generate larger WAL regarding GIN index - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: HEAD seems to generate larger WAL regarding GIN index
Date
Msg-id 53306DEA.8070803@vmware.com
Whole thread Raw
In response to Re: HEAD seems to generate larger WAL regarding GIN index  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Useless "Replica Identity: NOTHING" noise from psql \d
Next
From: Tanmay Deshpande
Date:
Subject: About adding an attribute to pg_attibute