Thanks for the reply Brad, two questions about your situtation: (1) The speedup only applies because of concurrent queries, right? With sequential queries you would expect no speedup?
(2) If you have 180 underlying tables, then each query to the merge table has to do 180 separate index lookups, right? Tom. On 24 Dec 2005 02:08:12 -0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Tom Cunningham writes: > >(a) The docs say that spreading the underlying tables across different > >disks can make queries faster. I don't quite understand how this will > >work in a normal query: if I do a SUM(amount) over the entire table, > >will it be quicker if the table is spread across different disks? I > >don't see how mysql can avoid doing this sequentially. > > Tom, > Multiple disks definitely helps, since in my case it allows me > to have N times the available read speed and N times the available > number iops (IOs/sec). In my case I have a 61GB merge table that > is based upon 180 separate myisam tables. This table contains 487M > records. The kinds of queries I'm doing, I would not be able to > handle cleanly without merge tables on 4.1.15. > > Since trying to back this up would be a nightmare, I rely upon > a standby master, and 3 query slaves for this data. This way things > work reasonably, and I have some hope of surviving some kind of > hardware failure. This is just one small portion of the substantial > data set I'm responsible for over at Technorati. > Brad Eacker ([EMAIL PROTECTED]) > [EMAIL PROTECTED] > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
