Re: scalability of MySQL - future plans?

2004-11-12 Thread Udi . S . Karni
Adequate data warehouse performance requires more than just hardware. 2 crucial make-or-break software features are partitioning and parallel query. On very large tables - accessing a large slice of the data via index is completely unfeasible. Table scan is the only option. Partitioning allows

Re: [OT] HP DL760G2 vs Opteron for large DB on Linux

2004-10-04 Thread Udi . S . Karni
It's a great server (the DL760 G2). They really opened up the bus and the Xeon 3.0 is superfast. "darren" <[EMAIL PROTECTED]> 10/03/2004 07:51 PM To: [EMAIL PROTECTED] cc: Subject:[OT] HP DL760G2 vs Opteron for large DB on Linux Hi all, I am looking

Re: Mysql growing pains, 4 days to create index on one table!

2004-07-16 Thread Udi . S . Karni
Here's another option to load without requiring a primary key (requires a LOT of extra disk space and fast CPU, and a batch window to run). Load the new daily data into the table without checking for dupes. Then create a new version of the table with distinct values. Something like this (assumi

Re: Mysql growing pains, 4 days to create index on one table!

2004-07-15 Thread Udi . S . Karni
Reordering the primary key wouldn't necessarily speed up the key check. The reason for selecting a particular sequence within a primary key is to put the columns that are available the most often - upfront - so that the index will have at least something to bite on. Can you parittion further? Y

Re: Mysql growing pains, 4 days to create index on one table!

2004-07-15 Thread Udi . S . Karni
That's the whole point. Eliminate your indexes and your load problems are solved. Especially given the fact that you insert ignore and don't use the primary key to validate uniqueness. matt ryan <[EMAIL PROTECTED]> 07/15/2004 11:38 AM To: cc: [EMAIL PROTECTED]