Hi Matthew, I've been toying with MVStore and seen this happening too. Setting read page cache is tricky, in my test case unless it is set to be quite big like starting to 64Byte*NUM OF ENTRIES big (depends on your datasize too), it wont yield a good performance improvement, it would actually slow down iteration performance as it will load/evict the cache (as with other cache too). ATM just don't set the cache and leave it to default(16M) and all is happy. My workaround for faster read is by implementing cache (like Guava, Caffeine, Cache2k, etc) in front of the KV
Like you i am liking the MVStore too, its a less known gem inside H2 hidden under its SQL layers. In my test it is the fastest for iteration and range scan, and yes i've tested RocksDB JNI. Point lookup not so much but again its easy to solve with hashmap based KV cache). If you could test with the default, and see how it actually consumes RAM in your particular case? Cheers Ahasani -- 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 https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
