I'm on 1.4.199 and I have tens of millions opaque data pieces in a DB instance. Currently they're stored as BINARY and I'm satisfied with both performance and stability (I'm using H2 in embedded mode). Most of these opaque data pieces are below the new limit of 1 MB but a few of them goes well above tens of megabytes. They're also handled well by 199 in my usage scenario.
1) Is an in-place LOB different from VARBINARY? Does it - like a non-in-place LOB - require additional read operation? 2) The LOB issue you mention looks like a stopper to me. Since large BINARY / VARBINARY works fine and do not cause OOM problems (at least in specific scenarios) would it be possible to add a new URL option that allows customization of the size limit for VARBINARY columns? On Wednesday, September 2, 2020 at 10:15:17 AM UTC+2 Evgenij Ryazanov wrote: > H2 ensures consistence of transactions for LOB values too, they aren't > special. > > But H2 has a long-standing issue with LOBs: > https://github.com/h2database/h2database/issues/1808 > In-place LOBs aren't affected, however. > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/922456f7-8898-439b-97f5-04705d0a4a83n%40googlegroups.com.
