Quote: > Number of joins in a view >63 > MariaDB has a limit of 63 tables joined in a select statement. This > needs to be extended in order to handle the many number of attributes > that may be connected to an anchor. Preferably a much larger number than > 63 in order to be 'future proof'.
== Amount of changes needed == This will require a substantial amount of changes: maria-5.3/sql$ grep table_map *.h *.c* | wc -l 520 On the other hand, a similar job was successfully done for "key_map" maria-5.3/sql$ grep key_map *.h *.c* | wc -l 118 and now MAX_INDEXES > 64 is supported as a compile-time option. The max number still needs to be reasonably low because there exist arrays like: ha_rows quick_rows[MAX_KEY]; Q: Will it be sufficient that the server supports >64 tables as a compile-time option? == Possible slowdown and max # of tables == Optimizer code uses table_map type as a set of tables and frequently passes around table_map objects by-value. Changing table_map from int64 to a complex type may slow things down. There are two possibilities: - table_map is changed to be bigger than int64 but is still passed by value. This is applicable if max# tables is 128 or 256. - table_map is changed to be a handle (pointer) to a bitmap of arbitrary size. Q: is limit of max. 128 tables sufficient, or we really need joins of arbitrary number of tables? == Estimates == Estimation will be done assuming: - MAX_TABLES > 64 is set on compile-time - MAX_TABLES is still reasonably-low number (e.g. 128 or 256)
Assuming: - MAX_TABLES > 64 is set on compile-time - MAX_TABLES is still reasonably-low number (e.g. 128 or 256) == List ot things to be done == - Redefine table_map to be Bitmap<N> (currently it is typedef'ed to uint64), fix all compile/test failures that will arise - Check all var[MAX_TABLES] arrays and replace them with more efficient structures, if necessary - Add tests for edge cases Estimate is: 3..4 weeks ( 15 - 20 work days)
Low Level Design modified. --- /tmp/wklog.243.old.18244 2011-10-27 07:52:03.000000000 +0000 +++ /tmp/wklog.243.new.18244 2011-10-27 07:52:03.000000000 +0000 @@ -9,5 +9,5 @@ structures, if necessary - Add tests for edge cases -Estimate is: 3..4 weeks +Estimate is: 3..4 weeks ( 15 - 20 work days)
Low Level Design modified. --- /tmp/wklog.243.old.18231 2011-10-27 07:51:47.000000000 +0000 +++ /tmp/wklog.243.new.18231 2011-10-27 07:51:47.000000000 +0000 @@ -1,7 +1,13 @@ -Tentative list of things to be done +Assuming: +- MAX_TABLES > 64 is set on compile-time +- MAX_TABLES is still reasonably-low number (e.g. 128 or 256) -- Redefine table_map to be Bitmap<N>, fix all compile/test failures -- Check all var[MAX_TABLES] arrays and replace them with - more efficient structures, if necessary -- Add a substantial number of tests for various edge cases +== List ot things to be done == +- Redefine table_map to be Bitmap<N> (currently it is typedef'ed to uint64), + fix all compile/test failures that will arise +- Check all var[MAX_TABLES] arrays and replace them with more efficient + structures, if necessary +- Add tests for edge cases + +Estimate is: 3..4 weeks
Low Level Design modified. --- /tmp/wklog.243.old.28790 2011-10-25 08:00:10.000000000 +0000 +++ /tmp/wklog.243.new.28790 2011-10-25 08:00:10.000000000 +0000 @@ -3,6 +3,5 @@ - Redefine table_map to be Bitmap<N>, fix all compile/test failures - Check all var[MAX_TABLES] arrays and replace them with more efficient structures, if necessary - - +- Add a substantial number of tests for various edge cases
Low Level Design modified. --- /tmp/wklog.243.old.10632 2011-10-24 20:37:52.000000000 +0000 +++ /tmp/wklog.243.new.10632 2011-10-24 20:37:52.000000000 +0000 @@ -1,2 +1,8 @@ +Tentative list of things to be done + +- Redefine table_map to be Bitmap<N>, fix all compile/test failures +- Check all var[MAX_TABLES] arrays and replace them with + more efficient structures, if necessary +
High-Level Specification modified. --- /tmp/wklog.243.old.10475 2011-10-24 20:34:56.000000000 +0000 +++ /tmp/wklog.243.new.10475 2011-10-24 20:34:56.000000000 +0000 @@ -9,7 +9,10 @@ maria-5.3/sql$ grep key_map *.h *.c* | wc -l 118 -and now MAX_INDEXES > 64 is supported as a compile-time option. +and now MAX_INDEXES > 64 is supported as a compile-time option. The max number +still needs to be reasonably low because there exist arrays like: + + ha_rows quick_rows[MAX_KEY]; Q: Will it be sufficient that the server supports >64 tables as a compile-time option? @@ -28,6 +31,9 @@ Q: is limit of max. 128 tables sufficient, or we really need joins of arbitrary number of tables? - +== Estimates == +Estimation will be done assuming: +- MAX_TABLES > 64 is set on compile-time +- MAX_TABLES is still reasonably-low number (e.g. 128 or 256)
High-Level Specification modified. --- /tmp/wklog.243.old.10085 2011-10-24 20:20:56.000000000 +0000 +++ /tmp/wklog.243.new.10085 2011-10-24 20:20:56.000000000 +0000 @@ -1,14 +1,32 @@ -* This will require lots of changes: +== Amount of changes needed == +This will require a substantial amount of changes: maria-5.3/sql$ grep table_map *.h *.c* | wc -l - 898 + 520 -* Changing table_map to be of arbitrary length may cause the optimizer become -noticeably slower. Changing the maximum to be 128 tables will probably reduce -the slowdown. +On the other hand, a similar job was successfully done for "key_map" -Q: are they happy if the server supports >64 tables as a compile option (like it -is currently for indexes. if you want >64 indexes, you need to re-compile) ? + maria-5.3/sql$ grep key_map *.h *.c* | wc -l + 118 + +and now MAX_INDEXES > 64 is supported as a compile-time option. + +Q: Will it be sufficient that the server supports >64 tables as a compile-time +option? + +== Possible slowdown and max # of tables == +Optimizer code uses table_map type as a set of tables and frequently passes +around table_map objects by-value. Changing table_map from int64 to a complex +type may slow things down. + +There are two possibilities: +- table_map is changed to be bigger than int64 but is still passed by value. +This is applicable if max# tables is 128 or 256. + +- table_map is changed to be a handle (pointer) to a bitmap of arbitrary size. + +Q: is limit of max. 128 tables sufficient, or we really need joins of arbitrary +number of tables?
Observers changed: Sergei
High-Level Specification modified. --- /tmp/wklog.243.old.6990 2011-10-24 19:06:49.000000000 +0000 +++ /tmp/wklog.243.new.6990 2011-10-24 19:06:49.000000000 +0000 @@ -1,2 +1,15 @@ +* This will require lots of changes: + + maria-5.3/sql$ grep table_map *.h *.c* | wc -l + 898 + +* Changing table_map to be of arbitrary length may cause the optimizer become +noticeably slower. Changing the maximum to be 128 tables will probably reduce +the slowdown. + +Q: are they happy if the server supports >64 tables as a compile option (like it +is currently for indexes. if you want >64 indexes, you need to re-compile) ? + +
