Fun with Table Functions
« previous entry | next entry »
Feb. 3rd, 2010 | 12:33 pm
I just about have all of the INFORMATION_SCHEMA replaced with Table Functions!
The big wins:
One Execution path (less bugs)
Simple interface, which means more langauges
Zero materialization happening
Less Code. This allows us to remove a lot of code (and single shot passes for particular use cases).
The data dictionary operates entirely off the proto system, so what you see is what we have. We use the table names stored within the proto so no translation ever happens. This is pretty handy for filesystems which do not preserve case (and we don't have to do anything to support them any longer).
You can also type "SELECT * FROM DATA_DICTIONARY.SCHEMAS".
There is no longer a "SCHEMATA" tables, just SCHEMAS. Want INDEXES? SELECT FROM INDEXES.
We will also be able to split up the tables that are from the SQL ANSI standard one from the ones that are not. The advantage is that we can provide an ANSI compliant INFORMATION_SCHEMA, and still have plenty of room to add additional tables as we see fit (yes, like the tables we provide today which house the information on the active Memcached cluster information).
The big wins:
The data dictionary operates entirely off the proto system, so what you see is what we have. We use the table names stored within the proto so no translation ever happens. This is pretty handy for filesystems which do not preserve case (and we don't have to do anything to support them any longer).
You can also type "SELECT * FROM DATA_DICTIONARY.SCHEMAS".
There is no longer a "SCHEMATA" tables, just SCHEMAS. Want INDEXES? SELECT FROM INDEXES.
We will also be able to split up the tables that are from the SQL ANSI standard one from the ones that are not. The advantage is that we can provide an ANSI compliant INFORMATION_SCHEMA, and still have plenty of room to add additional tables as we see fit (yes, like the tables we provide today which house the information on the active Memcached cluster information).
drizzle> use data_dictionary; Database changed drizzle> select * from plugins; +-------------------------------------------+-----------------------+-----------+-------------+ | PLUGIN_NAME | PLUGIN_TYPE | IS_ACTIVE | MODULE_NAME | +-------------------------------------------+-----------------------+-----------+-------------+ | ARCHIVE | StorageEngine | TRUE | TRUE | | ascii | Function | TRUE | TRUE | | benchmark | Function | TRUE | TRUE | | BLACKHOLE | StorageEngine | TRUE | TRUE | | char_length | Function | TRUE | TRUE | | character_length | Function | TRUE | TRUE | | CHARACTER_SETS | TableFunction | TRUE | TRUE | | COLLATIONS | TableFunction | TRUE | TRUE | | COLUMNS | TableFunction | TRUE | TRUE | | compress | Function | TRUE | TRUE | | connection_id | Function | TRUE | TRUE | | console | Listen | TRUE | TRUE | | crc32 | Function | TRUE | TRUE | | CSV | StorageEngine | TRUE | TRUE | | default_replicator | TransactionReplicator | TRUE | TRUE | | drizzle_protocol | Listen | TRUE | TRUE | | Error_message_stderr | ErrorMessage | TRUE | TRUE | | FunctionEngine | StorageEngine | TRUE | TRUE | | GLOBAL_STATEMENTS | TableFunction | TRUE | TRUE | | GLOBAL_STATUS | TableFunction | TRUE | TRUE | | GLOBAL_VARIABLES | TableFunction | TRUE | TRUE | | hello_world | Function | TRUE | TRUE | | INDEX_PARTS | TableFunction | TRUE | TRUE | | INDEXES | TableFunction | TRUE | TRUE |
What about ANSI compatibility?
from: anonymous
date: Feb. 3rd, 2010 10:13 pm (UTC)
Link
Why not keep the standard ANSI name?
Reply | Thread
Re: What about ANSI compatibility?
from:
krow
date: Feb. 3rd, 2010 10:18 pm (UTC)
Link
Now as far as INFORMATION_SCHEMA goes I would like to keep it clean of non-ansi schemas/have it represent just what is in the standard.
Reply | Parent | Thread