Hi. Just wondering if this is something that has been planned for MySQL...
If MERGE table are used, from the documentation, my understanding is that they are searched in sequence when a SELECT is issued. However, would it not be reasonably easy to implement a parallel search algorythm, so that the SELECT on each of the MERGE tables is done simultaneously, and then UNIONed together before it is returned? I understand that there is the fork penalty for this, but for big MERGE tables on an SMP system, this could improve the performance nearly linearly with the number of CPUs in the system. It could be limited to, say "thread_concurrency" SELECTS in parallel or something like that, in order to minimize the fork penalty to a useful level. Is this something that is planned? It just strikes me as a reasonably obvious place to implement parallel query execution for UNION SELECTs. This could then (I can dream, right?) be extended to performing UNION SELECTs across the whole replicated cluster (execute the SELECT on the "latest" MERGE table on the master/"insert/update host" to insure most up-to-date data is returned). That should REALLY start giving Oracle some competition in the "run a query across a cluster" feature set. :-) Am I missing something, and is there something in the current MySQL design that makes this difficult/implausible? It doesn't appear to be in the TODO list (but I might be looking at slightly out-of-date documentation)... Regards. Gordan --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
