Thomas, The MVStore is obviously your storage of choice going forward - and it has nice benefits. However, in my tests yesterday I inserted ( then updated a few times ) a total of 1,696,792 rows. This created a dbFile of 8.8GB in size. That works out to 5175.9 bytes per row. The pageStore version was closer to 500 bytes per row. That is a huge difference. But the real kick in the ass was when I shutdown my application - It took approx 30 minutes for the db lock file to clean-up so that application could be re-started. That is a show stopper.
I have re-worked my delete to calculate the number of rows I am deleting and I will add (n) deletes of 10000 records at a time into a jdbc batch statement. Hopefully this will prevent the OutOfMemory exception on the delete and I am returning to the PageStore. Thanks for all your work. On Thursday, July 17, 2014 11:33:19 AM UTC-4, Kenton Garner wrote: > > Thanks again Thomas, > > I downloaded your latest version and switched back to the MVStore. I am > running tests now. > One observation that i have noticed is that with the MVStore enabled the > database file is approx 6X the size of when I was using the PageStore. > I am at approx 1.2 Million messages and the database file is 6+ GB. When > I had 2.1 million records in the PageStore the database file was only about > 1GB. > > The change log indicated that you have just implemented the start of the > auto-compression for the MVStore. Do you expect to see better sizing as > this version matures? > Can you give a quick 10000 foot overview of the overhead differences so > that we can determine which version is best for us. > > I have plans to store actual message files in the database. I tested with > the PageStore version and was impressed with the compression I was > getting. > I am however, concerned with the MVStore version trying to store the same > files. > > I can post this question as a new thread if you prefer. > > > On Wednesday, July 16, 2014 3:37:59 AM UTC-4, Thomas Mueller wrote: >> >> Hi, >> >> > The MSGDATE field is part of the primary key >> >> Well, what *exactly* is the primary key? It's not enough if it's _part_ >> of the primary key, it needs to be the first column of an index. >> >> Out of memory: The problem could be MVCC in combination with the >> PageStore, I think this can run out of memory. Could you try using the >> MVStore? To do that, you would need to create a new database. >> >> Regards, >> Thomas >> >> >> On Wed, Jul 16, 2014 at 9:28 AM, Noel Grandin <[email protected]> wrote: >> >>> >>> >>> You shouldn't be getting OOM, even with very large deletes. >>> Try turning on the heap dump on OOM feature of the JVM, and then running >>> the Eclipse Memory Analyzer over the resulting dump. >>> That should point out the problematic code. >>> >>> >>> -- >>> 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/d/optout. >>> >> >> -- 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/d/optout.
