Re: Moving more work outside WALInsertLock - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Moving more work outside WALInsertLock
Date
Msg-id CA+U5nMJ4=CZ6qH0JTVWykHa_e2GPg+fv_Yy9Ye=7dy0zO7wLgg@mail.gmail.com
Whole thread Raw
In response to Re: Moving more work outside WALInsertLock  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Mon, Jan 9, 2012 at 2:29 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

>> Can we also try aligning the actual insertions onto cache lines rather
>> than just MAXALIGNing them? The WAL header fills half a cache line as
>> it is, so many other records will fit nicely. I'd like to see what
>> that does to space consumption, but it might be a useful option at
>> least.
>
>
> Hmm, that's an interesting thought. That would mean having gaps in the
> in-memory WAL cache, so that when it's written out, you'd need to stitch
> together the pieces to form the WAL that's actually written to disk. Or just
> leave the gaps in the on-disk format, if we're willing to change the WAL
> format for this, but I don't think we want make our WAL any larger than it
> already is.

I don't think that would require any format changes at all. We never
check that the total length of the WAL matches the size of the
contents do we? So if the record is just a little too big for its
contents, it will still all work fine. Recovery just calls rmgr
functions, so it doesn't know how big things should be. _redo routines
don't do local validation anywhere that I'm aware of. Sure, they cast
the record to a specific type, but that doesn't prevent the record
from being longer that _redo wants it to be. Try it.

You could probably do it for individual record types with an
additional rdata item.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Progress on fast path sorting, btree index creation time
Next
From: Joel Jacobson
Date:
Subject: Generate call graphs in run-time