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
