On 2/28/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
But we've already seen that CRC checks can be expensive. Not everyone will
want to take the cpu hit. Storing a byte counter in every block is cheap.

CRC checking a page is most certainly the simplest.  And, I disagree
that it would be worse than either a sequence counter or the full page
write.  Block checksumming is done at read/write time... which is
something that needs to be improved anyway.  With a properly tuned
bgwriter, the write itself should barely be noticeable.  How fast is a
CRC of 8K?  Last time I checked it was something on the scale of ~95
usec for CRC32 and ~33 usec for sb8.

And the idea came from what someone said MSSQL does, so "like everyone else"
-- which isn't a very compelling argument to begin with -- doesn't argue
against it.

Rather than basing designs on poor second-hand information, maybe you
and the person who mentioned this idea should get up-to-date and read
the SQL Server storage engine architecture.

As of SQL Server 2005, blocks *are* checksummed with CRC32.  And, just
for the record, previous versions of SQL server performed a bit
flipping technique for every 512 bytes in the page header; it did
*not* waste a byte for every 512 bytes written.

I think the way you would work is to have the smgr note the sequential value
it found when it read in a page and then when it writes it out increment that
value by one. Conveniently the pages would be 16 bytes shorter than an 8kb
page so you have 16 bytes available with every buffer to note information like
the last sequential tag the buffer used.

This proposed design is overcomplicated and a waste of space.  I mean,
we reduce storage overhead using phantom command id and variable
varlena, but let's just fill it up again with unnecessary junk bytes.

That seems pretty unlikely. CRC checks are expensive cpu-wise, we're already
suffering a copy due to our use of read/write the difference between
read/write of 8192 bytes and readv/writev of 511b*16+1*6 is going to be
non-zero but very small. Thousands of times quicker than the CRC.

Prove it.

Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation            | fax: 732.331.1301
33 Wood Ave S, 3rd Floor            | [EMAIL PROTECTED]
Iselin, New Jersey 08830            | 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

Reply via email to