On Wed, 2007-01-10 at 23:32 -0500, Bruce Momjian wrote: > Simon Riggs wrote: > > On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote: > > > Jim Nasby <[EMAIL PROTECTED]> writes: > > > > On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote: > > > >> Ok, so when you need CRC's on a replicate (but not on the master) you > > > > > > > Which sounds to me like a good reason to allow the option in > > > > recovery.conf as well... > > > > > > Actually, I'm not seeing the use-case for a slave having a different > > > setting from the master at all? > > > > > > "My backup server is less reliable than the primary." > > > > > > "My backup server is more reliable than the primary." > > > > > > Somehow, neither of these statements seem likely to be uttered by > > > a sane DBA ... > > > > If I take a backup of a server and bring it up on a new system, the > > blocks in the backup will not have been CRC checked before they go to > > disk. > > > > If I take the same server and now stream log records across to it, why > > *must* that data be CRC checked, when the original data has not been? > > > > I'm proposing choice, with a safe default. That's all. > > I am assuming this item is dead because no performance results have been > reported.
It's been on my hold queue, as a result of its lack of clear acceptance. Results from earlier tests show the routines which are dominated by CRC checking overhead are prominent in a number of important workloads. Those workloads all have a substantial disk component, so test results will vary between no saving at all on a disk-bound system to some savings on a CPU bound system. Restore RecordIsValid() #1 on oprofile results at 50-70% CPU COPY XLogInsert() #1 on oprofile results at 17% CPU (full_page_writes = on) OLTP no test with full_page_writes = on (less relevant) OLTP XLogInsert() #5 on oprofile results at 1.2% CPU (full_page_writes = off) Removing the CRC checks on WAL would likely be the easiest to remove 1% CPU on the system as it stands. Other changes require algorithmic or architectural changes to improve matters, though gains can be much larger. 1% doesn't sound much, but PostgreSQL is a very sleek beast these days. As we improve things in other areas the importance of this patch as a tuning switch will grow. Clearly the current patch is not accepted, but can we imagine a patch that saved substantial CPU time in these areas that would be acceptable? *Always* as a non-default option, IMHO, with careful documentation as to its possible use. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend