Hi,
I have a suggestion (two, in fact) : - add a 48-bit integer type, which would nicely fill in the gap between INT and BIGINT. Some value types are too large for INT but being forced to use BIGINT is really a waste (for example, millisecond-precise timestamps, or hash values over a collection of one million elements). - add the possibility to index only a prefix of an integer (like can already be done with strings). For example, index only the four high-order bytes of a BIGINT, so that searches remain fast but the index does not take too much place (especially when chances are low that ignoring some low-order bytes introduces many more duplicates). These two features would be really nice when one wants to optimize the space taken by a table. I have some large tables which only consist of five BIGINT columns with some single- and multiple-column indexes. All these columns and indexes would be candidates for both optimizations mentioned above, and it would yield probably 30% to 50% disk space savings, as well as maybe faster queries. I know, I could try to do it with CHAR(6) BINARY, but this is tricky and moreover I wouldn't be able to use arithmetic operations in MySQL (which is really annoying because application languages like Perl do not necessarily accept integers wider than 32 bits). Thank you Antoine. --------------------------------------------------------------------- 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
