Re: Maximum JOINED tables
* Benjamin Pflugmann > On Fri 2002-06-07 at 11:43:38 +0200, [EMAIL PROTECTED] wrote: > [...] > > 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: > > Well, of course, they could limit the join to 31 tables on all > platforms. > > But then people would start to ask, why this limit is artificially low > on 64 bit platforms. Well... :) I would agree to this if any 64 bit based functionality was limited to 64 bit platforms, but that is not the case. For instance, we can use BIGINT on all platforms. I don't think 'people' would think there is a connection between the processor word width and the number of joins in a single select... but of course, I could be wrong. I do not suggest that the limit should be lowered to 31 on all platforms, but I find it hard to believe that it is impossible to implement joins in a different way, so that the max number of joins would be the same on all platforms. Monty & company have of course worked hard to prevent platform dependency, and it seems as this is the only part of mysql directly dependant on the processor architecture. I find it strange, I don't say it is not true. > > What (other) features of mysql are dependant on the processor > > architecture? > > file size (indirectly... it is dependend on the OS, but the OS is > often dependend on the architecture). > > I can not think of any other, currently. If file size qualifies, then the table name letter casing issue and the differences in the floating point functions also qualifies. But all of these are OS dependant, not directly processor architecture dependant. And I think the number of joins in a query is a _feature_ on a different level. > [...] > > 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 can only guess, but I think it is still there, because increasing it > would be fruitless as long as finding the optimal join is in O(2^N). You are probably right. > Additionally, people seem to seldom need so many tables in a single > join, and that's probably, too, why the join order optimizer is still > the way it is. Yes... and seldom = sometimes... :) I don't know the limits for any of the other rdbms, but crashme reports +64 for IBM, Microsoft, Oracle and PostgreSQL. > > 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? > > I am not sure what your point is. Just making sure we are talking about the same thing. :) > The client will have to wait too long, no matter where the time is spent. The nature of my application allows for a relatively slow query preparation, because I have few simultaneous queries. I guess up to 0.2 sec could have been acceptable. (I want the answer within 0.5 sec.) Query execution time will always increase for each join you add to a select, but that was of course _not_ what you was talking about. I should have known better. :) > > 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...? > > Because people had problems with that in the past and asked on the > list for the reason and the answer (by Monty, I think) was that the > join order optimization takes the additional time (in comparison to a > STRAIGHT_JOIN). The delay was in the order of seconds, IIRC. Ah. Thanks. > You'd have to try out. Since the time is doubling with each table, > let's say 31 tables would need 100 secs, with 20 tables you would > hardly notice it, as it would be only 1/2048 of that, i.e. less than > 0.05 secs. Yes, I see. (31-20=11, 2048 = 11 bits) > You see why allowing 64 tables futile? Well... apparently it _is_ allowed on 64 bit platforms... :) But I understand why implementing it for 32 bit platform is not a prioritized task for the developers. > Presuming processing one order > would be as simply as one plain instruction, the join order optimizer > would need on a Pentium III 500 (225.4 MIPS): > > #tables > 10 0.045 secs > 20 0.0047 secs > 30 4.76 secs > 40 1.35 hours > 50 57.81 days > 60162.20 years > > Of course, real scaling will differ as pure MIPS don't show real > speed. But you get the idea. Yupp. Exponential growth. > For your purpose, you have to try out, if speed decrease with 30 > tables matters to you. Please post any result you find. Yes, I will do some tests during the next couple of week
Re: Maximum JOINED tables
Hi. On Fri 2002-06-07 at 11:43:38 +0200, [EMAIL PROTECTED] wrote: [...] > 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: Well, of course, they could limit the join to 31 tables on all platforms. But then people would start to ask, why this limit is artificially low on 64 bit platforms. > What (other) features of mysql are dependant on the processor > architecture? file size (indirectly... it is dependend on the OS, but the OS is often dependend on the architecture). I can not think of any other, currently. [...] > 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 can only guess, but I think it is still there, because increasing it would be fruitless as long as finding the optimal join is in O(2^N). Additionally, people seem to seldom need so many tables in a single join, and that's probably, too, why the join order optimizer is still the way it is. > 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? I am not sure what your point is. The client will have to wait too long, no matter where the time is spent. > 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...? Because people had problems with that in the past and asked on the list for the reason and the answer (by Monty, I think) was that the join order optimization takes the additional time (in comparison to a STRAIGHT_JOIN). The delay was in the order of seconds, IIRC. You'd have to try out. Since the time is doubling with each table, let's say 31 tables would need 100 secs, with 20 tables you would hardly notice it, as it would be only 1/2048 of that, i.e. less than 0.05 secs. You see why allowing 64 tables futile? Presuming processing one order would be as simply as one plain instruction, the join order optimizer would need on a Pentium III 500 (225.4 MIPS): #tables 10 0.045 secs 20 0.0047 secs 30 4.76 secs 40 1.35 hours 50 57.81 days 60162.20 years Of course, real scaling will differ as pure MIPS don't show real speed. But you get the idea. For your purpose, you have to try out, if speed decrease with 30 tables matters to you. Please post any result you find. Bye, Benjamin. -- [EMAIL PROTECTED] - 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
Re: Maximum JOINED tables
* Victoria Reznichenko > RB> mysql is considered to be platform independant, and I suppose > RB> MySQL AB is trying to keep it that way...? > > Roger, MySQL is platform independent. I did not say it was not... :) > It works on any platform with > the same data, but if the architecture is 64 bit, you can use it for more > power than on 32 bit. If the feature set is different on different platforms, the product is not truly platform independant. The number of joins in a query is a part of the feature set, IMHO. It is fully possible that right now someone is developing an application on a 64bit platform, not knowing that the system will not work on 32bit platforms simply because they have too many joins. It is not the 'lack of power' on 32bit platforms that will prevent it from working, it's the _platform dependant_ limitation in the number of joins. Ok, _now_ I am saying that mysql is not platform independant, but of course, this 'incompatibility' is not something most users will run into, so I guess we could say it is 99% true that mysql is platform independant, or that mysql is 99% platform independant... :) (There are also issues with letter casing in table names and different implementations of the floating point methods.) > You can change it (set 63) in 32 bit CPU by hack in compilation, but > making join map 64 bit on 32 bit box makes the work of MySQL slower. And in this case 'slower' means...? (If we are talking about milliseconds per query, I don't see the problem. If we are talking about milliseconds per traversed row, there would be a problem.) Has anyone ever done this hack, and if so, was the result usefull? Thank you for the info, Victoria! :) ...and sorry to those who got fooled by me pointing at crashme telling them the limit was 64 in 3.23.x... -- 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
Re: Re: Maximum JOINED tables
Roger, Friday, June 07, 2002, 12:43:38 PM, you wrote: RB> * 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. RB> Yes... a positive attitude makes life easier. :) RB> However, I think my question is valid... I don't think it is a good idea to RB> limit the number of joins based on the processor architecture, and this RB> makes me wonder what other 'strange' limitations I might find in mysql... RB> some questions to Victoria/MySQL AB: RB> mysql is considered to be platform independant, and I suppose MySQL AB is RB> trying to keep it that way...? Roger, MySQL is platform independent. It works on any platform with the same data, but if the architecture is 64 bit, you can use it for more power than on 32 bit. RB> Will the max number of joined tables (on 32-bit platform) stay at 31 in RB> version 4.x, or is it planned to increase this limit? I don't know. RB> Is this limitation "by design", and if so, why? (I suspect it is by RB> accident, and that's ok. That would mean it will probably be fixed in the RB> future.) You can change it (set 63) in 32 bit CPU by hack in compilation, but making join map 64 bit on 32 bit box makes the work of MySQL slower. -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.net http://www.ensita.net/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Victoria Reznichenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net <___/ www.mysql.com - 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
Re: Maximum JOINED tables
* 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
Re: Maximum JOINED tables
Hi. 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. > 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. 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. Bye, Benjamin. -- [EMAIL PROTECTED] - 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
Re: Maximum JOINED tables
* Victoria Reznichenko [...] > RB> So... is the crashme report wrong? Or was the limit really 32 > RB> in 3.22.39, got lowered to 31 in later versions (like 3.23.30- > RB> gamma), raised to 63 in version 3.23.39, and then lowered to > RB> 31 again (at least in versions 3.23.47 and 4.0.1)...? > > RB> http://www.mysql.com/crashme > > > RB> (Select both mysql versions, submit, and search for "tables > RB> in join" on the result page.) > > If you have 32 bit CPU you can use 31 tables in join. 63 tables with > 64 bit CPU. ok... thanks. :) But... is this the only feature of mysql which is dependant on the processor architecture? 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... -- Roger - 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
Re: RE: Maximum JOINED tables
Roger, Thursday, June 06, 2002, 12:08:13 PM, you wrote: >> I just tried a multiple self join on 4.0.1 and got the following >> >> DBD::mysql::st execute failed: Too many tables. MySQL can only >> use 31 tables in a join at ./x2.pl line 47. RB> Me too, running 3.23.30-gamma on w2k: mysql>> desc select * from RB> -> tab1 t1,tab1 t2,tab1 t3,tab1 t4... RB> ERROR 1116: Too many tables. MySQL can only use 31 tables in a join RB> So... is the crashme report wrong? Or was the limit really 32 in 3.22.39, RB> got lowered to 31 in later versions (like 3.23.30-gamma), raised to 63 in RB> version 3.23.39, and then lowered to 31 again (at least in versions 3.23.47 RB> and 4.0.1)...? RB> http://www.mysql.com/crashme > RB> (Select both mysql versions, submit, and search for "tables in join" on the RB> result page.) If you have 32 bit CPU you can use 31 tables in join. 63 tables with 64 bit CPU. RB> -- RB> Roger -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.net http://www.ensita.net/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Victoria Reznichenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net <___/ www.mysql.com - 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
RE: Maximum JOINED tables
* Harald Fuchs > In article <[EMAIL PROTECTED]>, > "Roger Baklund" <[EMAIL PROTECTED]> writes: > > > Yes... that is strange. There could be a bug in the crashme > > report, or the limit may have been lowered after 3.23.39, but > > neither of those seems very likely (to me, anyway)... anyone > > got a clue? > > I just tried a multiple self join on 4.0.1 and got the following > > DBD::mysql::st execute failed: Too many tables. MySQL can only > use 31 tables in a join at ./x2.pl line 47. Me too, running 3.23.30-gamma on w2k: mysql> desc select * from -> tab1 t1,tab1 t2,tab1 t3,tab1 t4... ERROR 1116: Too many tables. MySQL can only use 31 tables in a join So... is the crashme report wrong? Or was the limit really 32 in 3.22.39, got lowered to 31 in later versions (like 3.23.30-gamma), raised to 63 in version 3.23.39, and then lowered to 31 again (at least in versions 3.23.47 and 4.0.1)...? http://www.mysql.com/crashme > (Select both mysql versions, submit, and search for "tables in join" on the result page.) -- Roger - 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
Re: Maximum JOINED tables
* Arthur Fuller > > I have searched the manual without success. I want to know the maximum > > number of tables MySQL permits to be JOINed in a single SELECT > > statement. * Roger Baklund > According to crashme, it is 32 in 3.22.39 and 63 in 3.23.39. > > http://www.mysql.com/information/crash-me.php > * Weaver, Walt > Hmmm... we're running 3.23.47 here and have run into a 32 table join > limit... Yes... that is strange. There could be a bug in the crashme report, or the limit may have been lowered after 3.23.39, but neither of those seems very likely (to me, anyway)... anyone got a clue? -- Roger - 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
Re: Maximum JOINED tables
In the last episode (Jun 05), Sabine Richter said: > "Weaver, Walt" wrote: > > From: Roger Baklund [mailto:[EMAIL PROTECTED]] > > * Arthur Fuller > > > I have searched the manual without success. I want to know the > > > maximum number of tables MySQL permits to be JOINed in a single > > > SELECT statement. > > > > According to crashme, it is 32 in 3.22.39 and 63 in 3.23.39. > > > > Hmmm... we're running 3.23.47 here and have run into a 32 table > > join limit... > > And how long does it take to compile a 32-tables-statement? With the > gupta server a 14-tables-statement took 2 hours. That all depends on how complex your query is and the size of the tables. A query that takes 2 hours to run probably can be optimized a lot, though. -- Dan Nelson [EMAIL PROTECTED] - 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
Re: Maximum JOINED tables
And how long does it take to compile a 32-tables-statement? With the gupta server a 14-tables-statement took 2 hours. Sabine "Weaver, Walt" wrote: > > Hmmm... we're running 3.23.47 here and have run into a 32 table join > limit... > > --Walt > > -Original Message- > From: Roger Baklund [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 05, 2002 10:19 AM > To: mysql mailing list > Cc: Arthur Fuller > Subject: Re: Maximum JOINED tables > > * Arthur Fuller > > I have searched the manual without success. I want to know the maximum > > number of tables MySQL permits to be JOINed in a single SELECT statement. > > According to crashme, it is 32 in 3.22.39 and 63 in 3.23.39. > > http://www.mysql.com/information/crash-me.php > > > -- > Roger > > - > 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 > > - > 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 - 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
RE: Maximum JOINED tables
Hmmm... we're running 3.23.47 here and have run into a 32 table join limit... --Walt -Original Message- From: Roger Baklund [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 10:19 AM To: mysql mailing list Cc: Arthur Fuller Subject: Re: Maximum JOINED tables * Arthur Fuller > I have searched the manual without success. I want to know the maximum > number of tables MySQL permits to be JOINed in a single SELECT statement. According to crashme, it is 32 in 3.22.39 and 63 in 3.23.39. http://www.mysql.com/information/crash-me.php > -- Roger - 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 - 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
Re: Maximum JOINED tables
* Arthur Fuller > I have searched the manual without success. I want to know the maximum > number of tables MySQL permits to be JOINed in a single SELECT statement. According to crashme, it is 32 in 3.22.39 and 63 in 3.23.39. http://www.mysql.com/information/crash-me.php > -- Roger - 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
RE: Maximum JOINED tables
Yup, it'd be the answer to everything. :>) -Original Message- From: Andrew Hazen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 10:00 AM To: Weaver, Walt; 'Arthur Fuller'; 'mysql mailing list' Subject: RE: Maximum JOINED tables Would have been a little spooky if were '42'! :) Andrew Hazen -Original Message- From: Weaver, Walt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 11:51 AM To: 'Arthur Fuller'; mysql mailing list Subject: RE: Maximum JOINED tables 32. -Original Message- From: Arthur Fuller [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 9:48 AM To: mysql mailing list Subject: Maximum JOINED tables I have searched the manual without success. I want to know the maximum number of tables MySQL permits to be JOINed in a single SELECT statement. TIA, Arthur - 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 - 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 - 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
RE: Maximum JOINED tables
Would have been a little spooky if were '42'! :) Andrew Hazen -Original Message- From: Weaver, Walt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 11:51 AM To: 'Arthur Fuller'; mysql mailing list Subject: RE: Maximum JOINED tables 32. -Original Message- From: Arthur Fuller [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 9:48 AM To: mysql mailing list Subject: Maximum JOINED tables I have searched the manual without success. I want to know the maximum number of tables MySQL permits to be JOINed in a single SELECT statement. TIA, Arthur - 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 - 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 - 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
RE: Maximum JOINED tables
32. -Original Message- From: Arthur Fuller [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 9:48 AM To: mysql mailing list Subject: Maximum JOINED tables I have searched the manual without success. I want to know the maximum number of tables MySQL permits to be JOINed in a single SELECT statement. TIA, Arthur - 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 - 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