Skip site navigation (1) Skip section navigation (2)

Re: COMMIT NOWAIT Performance Option

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Subject: Re: COMMIT NOWAIT Performance Option
Date: 2007-02-28 17:16:39
Message-ID: 87tzx6urrc.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
"Gregory Stark" <stark(at)enterprisedb(dot)com> writes:

> We've already seen wal CRC checking show up at the top of profiles.
>
> Do you really doubt that memcpy is faster than CRC32 checking? Especially when
> you're already doing memcpy anyways and the only overhead is the few unaligned
> bytes at the end and the 8 one-byte copies?

Well color me surprised, writev is not nearly so much faster than CRC as I had
expected:

lseek+write syscall overhead: 	7.95  us
CRC32				32.54 us
writev				26.56 us

The reason there's lseek overhead in there is because I had it seek back to
the same block repeatedly to (hopefully) avoid any i/o. It seems to have
worked as I find it hard to believe these numbers could be so low if there's
any i/o being included.

I think part of the reason writev is slow is because I'm including the time it
took to set up the iovec array. That's 64 word copies write there. And then
writev has to read those 64 words back and do 64 extra branches and so on...

This is on an Intel T2500 (2Ghz).

There is a side issue that tagging each sector is 100% guaranteed to detect
torn pages whereas checksums still have a chance of missing them. But usually
the scenario where that comes into play is where you have many checksum
failures and are ignoring them assuming they never fail. In the case of torn
pages there'll only be one torn page and we're going to scream bloody murder
if we see it so I don't think that's a big issue.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Sergey E. KoposovDate: 2007-02-28 17:19:17
Subject: Re: SOC & user quotas
Previous:From: Bruce MomjianDate: 2007-02-28 17:16:10
Subject: Re: COMMIT NOWAIT Performance Option

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group