Hi, The cache size estimation is not exact. It depends on a lot of factors, for example the virtual machine (64 bit versus 32 bit), whether the values can be re-used (there is a value cache), and so on.
And also is it possible to lazily initialize fields of rows. The values in the row are not indexed (the values in a row are just stored one after the other), so lazily initializing the fields would be tricky. I would like to avoid parsing the (same) data multiple times, because that would slow down performance. Adding a value index would increase the size (both storage and in-memory), which I also want to avoid. Thinking about this, there might be a solution: columns should be read lazily from left to right only up the the point where needed. This would result in one or two additional integer per row (only in-memory), which might be acceptable. That would be a solution, I will add a feature request (but I will not implement it right now, sorry; it would be quite a large change I think). As Noel suggest, you could split the table in two: one only contains the columns that are used a lot, and the other table for the remaining columns. Regards, Thomas -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
