Hello Paul, I suggest you reply to the mailinglist :-) ...
> The developer insists that for scalability issues, this was the > answer. It is likely, for example in my deployment, that these tables > would see upwards of 10 million records or more. Well, if there are problems with scalability, I guess you could split it up in a few (not 1600) tables and have them avaialble on different physical hard drives... But -> why try to fix something that ain't broken (yet)? Were you experiencing problems already? If the application is fast WITHOUT merge tables, why bother? Martijn Tonies Database Workbench - development tool for MySQL, and more! Upscene Productions http://www.upscene.com My thoughts: http://blog.upscene.com/martijn/ Database development questions? Check the forum! http://www.databasedevelopmentforum.com > > > > > One of the databases I use just switched to using merge tables and now > > > my queries are painfully slow. One table, initially had about 2.5 > > > million records and now with the change this information is spread > > > across about 1600 tables. A simple query, say select count(*) has gone > > > from .04 to about 30 seconds, sometimes even longer. > > > > Why on earth would you spread this information across 1600 (!!!) > > tables? That's 1600 files to maintain instead of 1. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
