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 match
