* Alvaro Herrera <[EMAIL PROTECTED]> [081002 16:18]: > > And, this still seems to have an issue with WAL, unless Simon's > > original idea somehow included recording hint bit settings/dirtying > > the page in WAL. > > I have to admit I don't remember exactly how it worked :-) I think the > idea was avoiding setting the page dirty until a certain number of hint > bit setting operations had been done (which I think means it's not > useful for the present purpose).
How crazy would I be to wonder about the performance impact of doing the full_page_write xlog block backups at buffer dirtying time (MarkBufferDirty and SetBufferCommitInfoNeedsSave), instead of at XLogInsert? A few thoughts, quite possible not true: * The xlog backup block records don't need to be synced to disk at the time of the dirty but they can be synced along with stuff behind it, although it *needs* to be synced by the time the buffer write() comes long, otherwise we haven't fixed our torn page probem, so practically, we may need to sync it for guarentees * OLAP workloads that handle bulk insert/update/delete are probably running with full_page_writes off, so don't pay the penalty of extra xlog writing on all the hint-bits being set * OLTP workloads with full_page_writes on would have some extra full_page_writes, but I have a feeling that most dirtied buffers in OLTP systems are going to get changed by more than just hint-bits soon eonugh anyways, so it's not a huge net increase * Slow systems that aren't high-velocity can probably spare a bit more Xlog bandwith anyways... But my experience is limitted to my small-scale databases... -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
