Re: Block-level CRC checks
От | Aidan Van Dyk |
---|---|
Тема | Re: Block-level CRC checks |
Дата | |
Msg-id | 20081002210700.GD16893@yugib.highrise.ca обсуждение исходный текст |
Ответ на | Re: Block-level CRC checks (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
* 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.
В списке pgsql-hackers по дате отправления: