On 13 Jul 2008, at 00:03, Stewart Smith wrote:
<snip>
We must also remember that some installations have 20,000+ tables. Having those all, constantly loaded in memory kinda sucks.
20,000 tables, definition stored in memory as simple SQL statements, plucking number out of sky, lets assume 2000 chars average for table definition. That gives us about 40 Mb of memory consumed. Low end consumer PCs ship with 512 Mb RAM - such as my Asus EeePC ultraportable. I think we can eat the cost of 40Mb of RAM for the sake of much reduced latency and simpler life. If you're still wanting to save some RAM, tokenize the SQL and then you can shrink the memory consumed by an order of magnitude.
Practical upshot - all the INFORMATION_SCHEMA operations will be quicker and won't need to hit the disk at all. Another practical upshot of tokenizing.... all field name compares turn into a int compare... no more would you need to iterate through the characters in a string. The lexer would feed into the parser 2 types of identifiers... a text string for unknown identifiers (maybe the user is creating a new table) and known identifiers for words already in the in-memory cache.
On large complex selects, has anyone actually looked to see how many string compares, and hash lookups occur in mysqld? Some of them are O(n*m^2) operations. Every identifier is already checked against a hash table at least once in the lexer... why not make it count for something?
Regards, Antony. _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
