-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stewart Smith wrote: > On Mon, Apr 13, 2009 at 07:35:47PM -0400, Michael Izioumtchenko wrote: >> but really, are they fast? What are Drizzle's plans about I_S? > > Likely turn it into an engine, and have hooks for other plugins to > provide tables. Thanks to the FRM removal and (ongoing) discovery work, > this should be simple.
Please, please, no! I_S != storage engine I_S is an interface to metadata, and should live *above* the storage engine level IMHO. There are two interfaces to the metadata which need to be resolved: * Internal (and plugin<->kernel) interface to get/set metadata * SQL interface The SQL interface is already done: it's pretty much standardized at this point and people understand it. But...when I think of the I_S, I actually think of the interface between plugins and the kernel and within the kernel itself for communicating changes in metadata. It would be grand if we could work on an implementation in 3 distinct phases: 1) Create a GPB Message class (and/or subclasses) which would encapsulate a change in some metadata 2) Create an internal interface which *only* uses these aforementioned GPB Message classes in its interface parameters 3) Implement the interface to be engine-agnostic and queryable by any engine. Just my two cents, Jay >> And the data dictionary and/or runtime memory only statistics? Both >> could be useful services for any DB engine. > > runtime memory statistics does need some work, but it shouldn't be hard > to get right. > >> I'd imagine an ideal statistics module to be a memory only database >> engine with UNCOMMITTED READ as the only > > Yes - you scan the values, either computed on-fly or already stored. > certainly READ UNCOMMITTED style isolation. > > But this is more performance schema than information schema. There is a > solid case to be made that I_S tables should be consistent and READ > COMMITTED (at least). > >> isolation level. It could also employ shared memory so people could >> write risky but fast readonly > > All read only. write values are configuration. > >> clients that would forgo some locking at the expense of an occasional >> clientside SEGV. > > Note that this wouldn't be client side, this would be *server* side as > all the I_S magic has to happen in server. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknkqvkACgkQ2upbWsB4UtE6xgCeJEKCpya6JupdaRJ1i2ttArPG lPUAnRonWhOs0eyp1OghEgkFJiKB276N =QJjE -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
