On Thursday 15 June 2006 8:52 pm, Daniel Noll wrote: Sigh. If you're doing an insert on a table with an identity column, then yes I believe that the index would be in memory. Or a memory page that was cached.
But you're missing the point. When do you get the max() value of the index? ;-) And why do you need it? ;-) ... The point is that you don't need it. If the insert has a value X for the identity column and X > CSV, then set CSV = X; It works every time. > Michael Segel wrote: > >> Presumably he column would be indexed if you're doing operations like > >> max() on it anyway, so efficiency isn't the problem. I suspect the > >> problem would be what to do when two users tried to insert rows at > >> around the same time. The second would fail to commit the transaction > >> and have to try again. > >> > >> Daniel > > > > No. > > First, you're still returning a value from the sequence that will cause > > an exception. So you have overhead. Also you'd have a lot harder time > > trying to manage the inserts. Also, you have to consider that its cheaper > > to get a value from memory than it is to apply the max() function on a > > value from the index. > > Ah. I was making the assumption that the indexes were implemented > "properly." For instance, an index should keep a certain amount in > memory in order to have a reasonable chance of running quickly. So the > max and min should already be in-memory. > > I take it that Derby doesn't do this? > > Daniel
