On Thu, 2007-07-26 at 22:37 -0400, Tom Lane wrote:
I've been looking at the way that the async-commit patch conserves
shared memory space by remembering async commit LSNs for groups of
transactions on a clog page, rather than having an LSN for each
individual transaction slot. This seems like a good plan to me,
but I'm confused about one point. The README text claims that each
LSN represents a contiguous group of transactions, that is, with the
proposed parameters each LSN would represent 256 sequential
transactions. However, it looks to me that what the code is actually
doing:
#define GetLSNIndex(slotno, xid)((slotno) * CLOG_LSNS_PER_PAGE + \
(xid) % (TransactionId)
CLOG_XACTS_PER_LSN)
results in transactions that are spaced 256 XIDs apart sharing the same
LSN slot. I'm not sure whether the code is good and the README is
bogus, or vice versa.
Well, in this case the README correctly expresses my intention and the
code does not.
Sharing LSNs among contiguous groups of XIDs
seems appealing because you'd expect that such a group would have
relatively close LSNs, and so not much information is lost. OTOH, the
modulo idea is interesting too, because if the transaction rate is less
than 256 commits per walwriter cycle, you'd effectively have exact
information for all the currently unflushed transactions. But the
downside is that transactions that are really quite old might
transiently appear un-hintable because some later transaction that
happens to share that LSN slot isn't flushed yet.
The modulo idea was my original intention and I attempted to change this
in v23. The above paragraph is pretty much how my thoughts evolved and
now I'm fully on the side of contiguous rather than striped, even though
the code says differently.
BTW, I don't think I believe at all the arguments given in the README
about what CLOG_LSNS_PER_PAGE should be, particularly since possible
changes in BLCKSZ weren't factored in. I'm inclined to set it so
that the LSNs take up the same amount of space as the clog buffers
themselves, ie, BLCKSZ/8 LSNs per page.
Sure, BLCKSZ should be factored in. Do we really need so many LSNs
though?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
