Thank you for the response Evgenij, The databases are quite flat. No CLOB/BLOBs, foreign keys or anything fancy etc. They do contain a couple of dozens of tables with up to a couple of dozen columns. And some of the tables may contain up to 50K rows. In PageStore and newly created MVStore terms most databases are no larger then 400Mb. I have only a couple of databases that are considerably larger.
Query results being buffered into the database sounds plausible although it is strange that such buffering seems to take place after the result set has been read and the connection is closed. But at least it puts a theoretical boundary on its potential size because I can predict what types of queries will be used on the databases. It would be good to know how/if this buffer space is reclaimed or reused. I know I can shrink the database by dump/restore but perhaps there are alternatives to that. I will experiment with LAZY_QUERY_EXECUTION. PageStore has been proven to be very stable. But it's lower concurrency is causing some performance issues here and there. Converting to MVStore has helped a lot so we would be very interested in converting more databases. -- 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.
