Unfortunately there is no easy way to change an index in-flight, it gets set as memory or disk based at creation time.
If you are unable to change your query, you could also try patching H2 and running a custom build with the indexes set to disk based On 24 April 2017 at 18:22, James Hurley <[email protected]> wrote: > Hi Noel, > > I appreciate you taking the time to look into this issue; I'll let the > team know that there is not an immediate solution and we can discuss the > suggestion you've given. > > On a different note, would it make sense to add a setting that gives the > database a threshold for when to force the indices for a temporary table to > disk? I'm thinking of something similar to the way that MAX_MEMORY_ROWS > works so that some resource usage tuning could be performed when working > with fairly large tables. Understandably this may impact performance once > the threshold is reached and the index is persisted but this is better than > a sudden (and unexpected) heap memory issue. Such a setting would also > give people a way to better manage the performance verses resource trade > off if they find themselves in a similar situation to ours. > > -- > 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. > -- 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.
