* Benjamin Pflugmann > On Thu 2002-06-06 at 19:17:10 +0200, [EMAIL PROTECTED] wrote: > [...] > > > But... is this the only feature of mysql which is dependant on the > > processor architecture? > > See it the other way: You are not garantueed more than 31 tables in a > join. If you happen to have a 64Bit architecture, you can use more.
Yes... a positive attitude makes life easier. :) However, I think my question is valid... I don't think it is a good idea to limit the number of joins based on the processor architecture, and this makes me wonder what other 'strange' limitations I might find in mysql... some questions to Victoria/MySQL AB: mysql is considered to be platform independant, and I suppose MySQL AB is trying to keep it that way...? What (other) features of mysql are dependant on the processor architecture? Will the max number of joined tables (on 32-bit platform) stay at 31 in version 4.x, or is it planned to increase this limit? Is this limitation "by design", and if so, why? (I suspect it is by accident, and that's ok. That would mean it will probably be fixed in the future.) > > I'm kind of nervous about this, because I'm currently working on a 'very > > normalized' database schema, and it is possible I will need more than 31 > > tables in a single select... including multiple joins to the > > same tables, of > > course. It would be very bad if my design turned out to be 64-bit > > dependant... > > AFAIK, if you need so many tables, you get a major problem: MySQL > figures out the best join order by trying all combinations. This > becomes increasingly slow as you are going to join more tables. In > other words: Trying to use 30 tables in one select probably will be > too slow as that it would matter whether so many tables are allowed in > a join or not. hm... The join order optimization is done before the query is executed, so I guess you are not talking about the _query_ beeing to slow, but the _preparation_ of the query... right? How slow are we talking here...? Normally the join order is decided within 0.001 sec... (I'm only guessing) When you say slow, do you mean 0.01, or 0.1 or 1.0 sec or what? In our current implementation of this system, we have about 20 tables in the main select statement, and we have never seen this problem. Will it be a problem with 24 tables? 28 tables? You probably don't know the answer to these questions, but maybe you can tell me more about why you suspect 30 tables would be too slow...? > Of course, you could work around it by using STRAIGHT_JOIN, but I > assume it is to cumbersome to figure out the optimal join order for > all SELECTs. I was kind of hoping mysql would do that for me... but I guess I could use a combination, using STRAIGHT_JOIN for some of the joins. I can split my query in two (or more), but I hope I don't have to, because I suspect this will slow down the performance, and I need to "always" have a result within 0.5 sec... -- Roger sql --------------------------------------------------------------------- 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
