Hi List,
I was just updated scripts/create_tables.sql so that it could be used easier in general as well as used on the automatic demo site in a fashion (mainly I it drops the tables before adding them, to avoid errors and get the latest versions possible).
Looking thru it, I noticed they are very uneven in how they handle integers: PMA_bookmark.id - INT(11) AUTO_INCREMENT PMA_table_coords.pdf_page_number - INT PMA_pdf_pages.page_nr - INT(10) UNSIGNED AUTO_INCREMENT PMA_column_info.id - INT(5) UNSIGNED AUTO_INCREMENT PMA_history.id - BIGINT UNSIGNED AUTO_INCREMENT
All of the fields should be unsigned first of all, signed values don't make sense for them.
BIGINT is defeintly overkill for the data, it should get changed to INT at least. We aren't going to have more than 2^32-1 history items AFAIK ;-).
For my biggest MySQL box, I had a total of 22 databases, 180 tables and 897 fields. This comes to 127mb of data I have. So that's a a INT(3) I could use on PMA_column_info.id already. However, for larger installs, I don't know if INT(5) would be enough.
AFAIK there are no performance boosts/losses for using smaller/larger INT(n) sizes, the only thing that happens is that you need to sort them out if you get bigger numbers than that. Could we just set all of them to INT(11) as the maximum ? (that's the largest value that makes any difference [-2147483648] as well as the default for 'INT').
Hi Robin!
AFAIK there are no performance boosts/losses for using smaller/larger INT(n) sizes, the only thing that happens is that you need to sort them out if you get bigger numbers than that. Could we just set all of them to INT(11) as the maximum ? (that's the largest value that makes any difference [-2147483648] as well as the default for 'INT').
I concur with that. +1 on changing it to INT(11) from the History-BIGINT-guy. ;)
Regards, Garvin.
Robin H. Johnson a écrit:
Hi List,
I was just updated scripts/create_tables.sql so that it could be used easier in general as well as used on the automatic demo site in a fashion (mainly I it drops the tables before adding them, to avoid errors and get the latest versions possible).
Looking thru it, I noticed they are very uneven in how they handle integers: PMA_bookmark.id - INT(11) AUTO_INCREMENT PMA_table_coords.pdf_page_number - INT PMA_pdf_pages.page_nr - INT(10) UNSIGNED AUTO_INCREMENT PMA_column_info.id - INT(5) UNSIGNED AUTO_INCREMENT PMA_history.id - BIGINT UNSIGNED AUTO_INCREMENT
All of the fields should be unsigned first of all, signed values don't make sense for them.
BIGINT is defeintly overkill for the data, it should get changed to INT at least. We aren't going to have more than 2^32-1 history items AFAIK ;-).
For my biggest MySQL box, I had a total of 22 databases, 180 tables and 897 fields. This comes to 127mb of data I have. So that's a a INT(3) I could use on PMA_column_info.id already. However, for larger installs, I don't know if INT(5) would be enough.
AFAIK there are no performance boosts/losses for using smaller/larger INT(n) sizes, the only thing that happens is that you need to sort them out if you get bigger numbers than that. Could we just set all of them to INT(11) as the maximum ? (that's the largest value that makes any difference [-2147483648] as well as the default for 'INT').
+1
Thanks,
Marc
-
Garvin Hicking -
Marc Delisle -
Robin H. Johnson