Hi Gary,
Yeah... we thought about those. Sergei said:
"you'll have hundreds of keys on one key page, so logarithm base will be few hundreds, and log N should be just 3-5. That is, it should be only ~3-5 times slower as compared to the table with one hundred rows."
So say key base is 200, log 200 (10^9) = 3.91 Splitting it into 10 smaller tables would make log 200 (10^9) = 3.47, which isn't a huge amount of difference I guess.
Still, worth testing to see how it performs in practice I guess. Thanks for the tip :)
Cheers, -Phil
----- Original Message ----- From: "Gary Richardson" <[EMAIL PROTECTED]>
To: "Phil Bitis" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 21, 2004 2:45 AM
Subject: Re: B-tree index question
If you are using MyISAM tables, have you thought about using MERGE tables instead? You could partition your table into several smaller tables. I don't know how the performance would be on a billion record table, but from my understanding it would shrink your index down.
http://dev.mysql.com/doc/mysql/en/MERGE.html
On Wed, 20 Oct 2004 11:09:43 +0100, Phil Bitis <[EMAIL PROTECTED]> wrote:Thanks for the informative reply Sergei,
We're actually just using an INT field at the moment, we were going to move
over to BIGINT when we start using 64-bit MySQL (soon).
Do you know where I should look for information on writing our own table
handler?
Thanks, -Phil
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
