On Tuesday, 21 April 2020 13:12:01 UTC+3, MacMahon McCallister wrote: > > > > On Tuesday, 21 April 2020 11:18:02 UTC+3, Noel Grandin wrote: >> >> Which version is this ? >> >> And what happens when you remove the dangerous options? (LOG and UNDO_LOG) >> > > Version: 1.4.200. > Nothing happens if i remove the options. I actually tried fiddling with > the options earlier, but it always halts on 5M rows. > > On Tuesday, 21 April 2020 11:30:20 UTC+3, Evgenij Ryazanov wrote >> >> If you don't have an index on GROUP BY column, you need a lot of memory >> for such queries in H2. >> >> > This does make kind of sense, but still not in this test-scenario. How > come the previous test-cases (up to 1M rows, without index), run fine, even > with memory as low as -XmX256m: > Executing with size: 1000 > Processed 1000, time 30 ms > Executing with size: 10000 > Processed 10000, time 50 ms > Executing with size: 100000 > Processed 100000, time 241 ms > Executing with size: 1000000 > Processed 1000000, time 1925 ms > > To respond to myself, actually, the Xmx settings didn't apply properly and therefore (as suggested earlier) the h2 operation ran out of memory. It seems, that actually using heap settings of Xmx1024 is able to execute the unindexed query on a table with 5M rows within 10 seconds.
But a follow up question - for these "un-indexed group by" scenarios, does h2 have to read all the result-set into memory? And besides indexing the table (which I can not too probably) are there any other optimizations to consider? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/ee3720aa-d375-4681-bcb0-9b43023716b7%40googlegroups.com.
