"Tom Lane" <[EMAIL PROTECTED]> writes: > "Simon Riggs" <[EMAIL PROTECTED]> writes: >> COPY XLogInsert() #1 on oprofile results at 17% CPU >> (full_page_writes = on) > > But what portion of that is actually CRC-related? XLogInsert does quite > a lot. > > Anyway, I can't see degrading the reliability of the system for a gain > in the range of a few percent, which is the most that we'd be likely > to get here ... for a factor of two or more, maybe people would be > willing to take a risk.
Well the problem with that is when you have dozens of 1% improvements which are additive and the net negative effects aren't additive. Since we can't quantify the effect on reliability here it's hard to tell if that's the case. What did you think about protecting against torn writes using id numbers every 512 bytes. That "improves" the reliability of the system in that it detects torn writes 100% of the instead of just (2^32-1)/2^32 (or 99.99999998%) of the time. (which poking a hole in the CRC mechanism would reduce to (2^31-1)/2^31 (or 99.99999995%)). I don't think either of those percentages are significant. If you crash your system once a day and always get a torn WAL page you're still far more likely to still get corrupted data due to cosmic rays long before you get corrupted data due to mistakenly applying a torn page from WAL. But if we can save CPU on every WAL write while not harming reliability (in fact increasing it, albeit insignificantly) why not? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
