I was thinking about full-page writes again tonight. I'm still
wondering about the feasibility of getting rid of full-page writes for
certain operations. We can do this, I think, in any case where we can
convince ourselves that if the original operation, or a redo of the
original operation, leaves behind a torn page, a subsequent redo will
still DTRT.
I think that both tuple freezing (XLOG_HEAP2_FREEZE) and heap
deletions (XLOG_HEAP_DELETE) are close to having this property. The
updates are pretty much unconditional - they certainly don't depend on
existing xmin/xmax/ctid/infomask bits being in any particular state.
But this (in the redo logic) is a problem:
if (XLByteLE(lsn, PageGetLSN(page))) { UnlockReleaseBuffer(buffer); return;
}
A crash might leave the updated LSN on disk, while the rest of the
page isn't. If this is workable at all, we'd need to at least
suppress the above behavior (I believe it would still be OK after we
reach consistency, but not before).
Tonight I realized that I think we could also make this property hold
for updates, only with respect to the block containing the *old* tuple
(which is basically getting the equivalent of a delete). While
reducing WAL just for deletes and freezing might be judged not worth
the additional complexity, maybe being able to improve the update case
would put it over the top.
Thoughts? Any idea how much of our WAL volume comes from FPIs vs.
everything else? Index changes vs. heap changes?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
