* Alvaro Herrera <alvherre@commandprompt.com> [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
withstuff behind it, although it *needs* to be synced by the time the buffer write() comes long, otherwise we haven't
fixedour 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
penaltyof 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
dirtiedbuffers in OLTP systems are going to get changed by more than just hint-bits soon eonugh anyways, so it's not a
hugenet 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,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.