Something does not click here:
If you have "a table with millions of rows and an assumed column width of
4MB of data", then how it is possible, that
"with set to 1000 the index creation still required a maximum heap of about
800M, but the OOM Error did not occur anymore" ?
Your thousand rows
On Wed, 22 May 2019 at 11:52, Noel Grandin wrote:
>
> One workaround is that you can use EXCLUSIVE_MODE for index creation:
>
>
meh, ignore me, that won't help.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and
One workaround is that you can use EXCLUSIVE_MODE for index creation:
http://h2database.com/html/commands.html#set_exclusive
--
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,
Thanks. I will take that into account.
--
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send
This could be another optimization, but that wont help if I have a table
with millions of rows and an assumed column width of 4MB of data.
With 4 GB heap, any value of MAX_MEMORY_ROWS > 1000 will lead to OOM Error
when selecting from that table.
And a value of 1000 might not be high enough for
On 2019/05/22 11:21 AM, Silvio wrote:
To determine our options I would like to raise my earlier question again: is there a binary difference in
MVStore/PageStore formats between version 199 and 196? In other words: would it be safe to revert to 196 without doing
dump/recreate cycles for all
Yesterday evening at about 20:00 another database on one of our servers got
corrupted (at least that is when errors started appearing in the logging).
There was limited server load at the time. In this case it was a database
of about 850Mb.
To determine our options I would like to raise my
