Hi, currently you serialize pages into intermediate ByteBuffer and then write > it to the FileChannel (I believe you gonna abstract this). >
The file system abstraction is already used, but yes, the data is first written to a ByteBuffer. I'm talking that in some situations it would be beneficial to avoid this > intermediate ByteBuffer at all. > I guess in most cases people will want to use regular Java objects on the client side (String, Integer, Long,...) - in that case there is no (efficient) way I know to avoid copying the data first to a ByteBuffer. I guess what you mean is that if an application uses Map<..., ByteBuffer> or Map<..., byte[]>, the MVStore should avoid copying the data. It could be done, but I'm not sure if this is such an important use case to justify the added complexity. It might make sense if you store relatively large binaries, but I'm not sure. In such cases, it might make sense to store the binaries outside of the database in their own files, just because freeing up disk space would be a lot simpler that way. The MVStore is really more about database records and not so much about really large binaries. 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.
