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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers