On Mon, Oct 20, 2008 at 09:50:30AM -0400, Jim Starkey wrote: > MySQL resolved the issue with a typically Ronstromian Dictat of "the > rule is that there are no rules", leaving it to individual storage > engines to manage the namespace and semantics of whatever a tablespace > might be, leading the situation where the storage engine name is an > explicit part of a tablespace identifier.
1 sqld has local engine tablespace named 'foo' 2nd sqld does not on 2nd sqld, issue create tablespace 'foo' in distributed engine on 1st sqld, create table using tablespace 'foo' in distributed engine. You either end up in being able to create tables on some sqlds and not others, or having engine name as part of the key for tablespaces, or rewriting your distributed protocol to include every sql node connected to the cluster (a no-go as they're unreliable, slow and you'd probably end up with timeouts more often than metadata ops). Also, you could have generic tablespaces implementations. for engines such as MyISAM, CSV, ARCHIVE etc that just write to file system. This would likely be a big boost on crappy file systems. -- Stewart Smith _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
