Re: Enable 32K Block in 8K Block DB

Yeah...what you said...

"Indexes want large block sizes". I was always leery of this assumption
when it first came out. The idea was that if one used a larger block size for their indexes, then the branching factor in the B-tree index would increase, thereby requiring less blocks to store the index, thereby lowering the height of the B-tree index, thereby improving performance due to less block accesses. At least that is how the theory goes. I still haven't seen a good proof on this. And as you state, contention can be a major issue. If you went from a 4K block to a 32K block size for you index, your leaf nodes will have roughly 8 times the number of leaf entries.

Without tearing about the rest of that short article, I got a big chuckle out of this one: "appropriately place tables and indexes into tablespaces that are optimally sized in order to reduce disk I/O." When I first read this, I asked myself what does the size of the tablespace have to do with reducing disk I/O? I'm assuming that it was meant that the "size" was the tablespace's block size.

At first, I wasn't sure Burleson wrote the above. The article does say that the above was an excerpt from a Rampant Techpress book. But on further investigation, the cited book was written by Burleson.

Cheers,
Brian

-- 
===================================================================

Brian Peasland
dba_at_remove_spam.peasland.com

Remove the "remove_spam." from the email address to email me.




"I can give it to you cheap, quick, and good. Now pick two out of

 the three"