Brian Aker wrote: > Hi! > > On Jul 12, 2008, at 1:27 PM, Antony T Curtis wrote: > >> >> UUID generation must be made good. It would be very useful for people >> in multi-master situation where they can have a column declared as: >> >> my_id HUGEINT NOT NULL PRIMARY KEY AUTO_UUID, >> >> Where AUTO_UUID is an alternative to AUTO_INCREMENT and the UUID would >> be returned in LAST_INDEX_ID() as expected. Then no need to worry >> about sharding the primary key: It should be very unlikely for pk >> collision. > > Why not just declare UUID a type like timestamp() which just fills > itself? Declaring it primary key is gravy (though for Innodb and similar > engines this has positives/negatives).
Brian, you understate the importance of the above statement. Clustered index organizations (especially ones with page-level block organization) generate a hot-spot in memory and on-disk when auto-incrementing primary keys are used. Essentially, with an auto-incremented primary key, the page's fill factor is typically 2-3x higher than with non-incrementing keys, which reduces or eliminates the need and costs of page-splitting and tree-rebalancing that is needed for the clustered index. If an engine with a clustered index organization knows that primary keys will always be higher than the last used key value, then many optimizations can be achieved, which is partly why InnoDB insert speeds on auto-incrementing primary keys are quite good (especially after the removal of certain locks and improvement the adaptive hash index in 5.1.21). Just thought I would mention this fact. And, Brian, I know you will respond that the cloud-computing space totally alters the above current situation, but I don't think it does. Having a cluster of InnoDB machines running with a UUID primary key would mean a dramatic increase in storage space used by InnoDB and, IMHO, a reduction in performance of modification statements. Our current system of replication with the auto_increment_increment method helps to increase insert speeds while ensuring uniqueness of primary keys across multiple servers. It's not ideal, of course, but it does have its performance advantages. My 2 cents and all that... :) -jay > Right now I want to see the generation improved upon. The current global > lock is an issue. My current feeling is to toss it if it is tree Ted's > library is better. > >>> Yep, we are of similar minds on this. To me SIGNED/UNSIGNED is really >>> just a constraint anyways. After consideration, I do agree with you, Brian, regarding signed being just a constraint. >> It would get rid of the val_int/val_uint mess and special case casting >> etc that mysql has right now. > > This is on the list. > > The proposal I first have for Field is the class break up of the files. > I've mentioned this on IRC, and I think I have mentioned it here as > well. Next week my focus will be more on install/cleanup. After that > this is something I either want to tackle or see someone else tackle. > > All in time :) > > Cheers, > -Brian > > -- > _______________________________________________________ > Brian "Krow" Aker, brian at tangent.org > Seattle, Washington > http://krow.net/ <-- Me > http://tangent.org/ <-- Software > _______________________________________________________ > You can't grep a dead tree. > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
