On Sun, May 31, 2009 at 11:00:48AM -0400, Jay Pipes wrote:
> There is, therefore, no need to have multiple implementations of the
> INFORMATION_SCHEMA interface. There is, however, a need to swap out the
> storage backend of the INFORMATION_SCHEMA -- think: I_S stored in
> InnoDB, I_S stored in memcached, etc.
I don't think having I_S have its own store is good....
it's really only VIEWs on top of data from other places. Currently:
- variables
- table and database metadata
- db.opt
- directories in data dir
- files ending in '.dfe' that get parsed okay.
- loaded plugins
- loaded collations
- whatever else I've missed.
The main problem with the current implementation being comparitive speed
of SHOW DATABASES/SHOW TABLES versus SELECT * FROM
INFORMATION_SCHEMA.TABLES stemming from the materialisation of the view.
so, if we look at listing databases, this is what happens:
- my_dir loads contents of directory into memory
- make_db_list reads that contents, works out if it's a database, stores
it in an array of database names
- I_S code writes this to a HEAP table
- HEAP table gets too big, writes to temp MyISAM table
- query executes (listing databases) using the handler interface on the
MyISAM table.
Where what we really want is a handler interface to readdir(3) (and
stat()) that we can execute the query on directly.
Although what we really, really want (hint: it's not zigazig ha) is to
have that readdir and stat be pluggable with whatever we want (e.g. a
scan on an engine data dictionary).
So there isn't really storage backends for I_S - rather a bunch of them
will pull their data from other stores. No need for them to be pluggable
as they're rather specific.
--
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
