> > > Well, this is actually relevant. You have two indexes (one primary key, > and a secondary key) on randomly distributed data. There is no way to make > it really fast, unless it fits in memory. Having to use an index on > randomly distributed data is a "cache killer". All you can really do in > this case is try to load everything in memory, or use a solid state disk. > > Because of that, I would avoid an index on randomly distributed data (no > matter what database is storage system you use), unless you know in advance > that the number of entries will never grow beyond a certain size, or unless > the amount of data you store is so big that the lookup cost (at most 200 > per second for a regular hard disk) is lower than the amount of data. That > means, each entry is about 2 MB in size or larger. >
> Regards, > Thomas > > > Does this mean that H2 now creates primary indexes on non integer based columns? The only info I could find was from a post of yours on stackoverflow from Oct 2010. This indicated that a hidden BigInt column would be created and that would become the primary index. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
