Re: B-tree index question

2004-10-21 Thread Sergei Golubchik
Hi! On Oct 21, Phil Bitis wrote: > >From: "Sergei Golubchik" <[EMAIL PROTECTED]> > > > >But for auto_increment field (on BIGINT, I believe ?), > >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-

Re: B-tree index question

2004-10-21 Thread Sergei Golubchik
Hi! On Oct 21, Mads Kristensen wrote: > *snip* > > Yes. > > B-tree is always balanced: http://www.nist.gov/dads/HTML/btree.html > > > > Regards, > > Sergei > *snip* > > You are right, B+Trees are always balanced but When you insert in > increasing order all your inserts will be to the last l

Re: B-tree index question

2004-10-21 Thread Phil Bitis
;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

Re: B-tree index question

2004-10-21 Thread Phil Bitis
From: "Sergei Golubchik" <[EMAIL PROTECTED]> But for auto_increment field (on BIGINT, I believe ?), 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 hund

Re: B-tree index question

2004-10-21 Thread Mads Kristensen
*snip* > Yes. > B-tree is always balanced: http://www.nist.gov/dads/HTML/btree.html > > Regards, > Sergei *snip* You are right, B+Trees are always balanced but When you insert in increasing order all your inserts will be to the last leaf of the B+tree. This means that you can get some concurr

Re: B-tree index question

2004-10-20 Thread Gary Richardson
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/my

Re: B-tree index question

2004-10-20 Thread Phil Bitis
ssage - From: "Sergei Golubchik" <[EMAIL PROTECTED]> To: "Phil Bitis" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, October 20, 2004 9:23 AM Subject: Re: B-tree index question Hi! On Oct 23, Phil Bitis wrote: Hello, We want to be able to inser

Re: B-tree index question

2004-10-20 Thread Phil Bitis
es of indexes, including primary keys? - Original Message - From: "mos" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 20, 2004 4:20 AM Subject: Re: B-tree index question Phil, The fastest method to load data into a table is to use "Loa

Re: B-tree index question

2004-10-20 Thread Sergei Golubchik
Hi! On Oct 23, Phil Bitis wrote: > Hello, > > We want to be able to insert records into a table containing a billion > records in a timely fashion. > The table has one primary key, which I understand is implemented using > B-trees, causing insertion to slow by log N. Corect. But for auto_increme

Re: B-tree index question

2004-10-19 Thread mos
At 04:15 PM 10/23/2004, you wrote: Hello, We want to be able to insert records into a table containing a billion records in a timely fashion. The table has one primary key, which I understand is implemented using B-trees, causing insertion to slow by log N. The key field is an auto_increment fiel

B-tree index question

2004-10-19 Thread Phil Bitis
Hello, We want to be able to insert records into a table containing a billion records in a timely fashion. The table has one primary key, which I understand is implemented using B-trees, causing insertion to slow by log N. The key field is an auto_increment field. The table is never joined to ot