Hi,
> The reason the varchars are in place is because they are representing
> Java UUID's outside the database which is required.
H2 supports the UUID data type, it should be faster than VARCHAR.
> Do have a recommendation on more optimal schedule that
> Analyze should run?
No. Usually ANALYZE is quite fast and not problematic.
> Each select query (although they are called in
> groups usually 1-5) would return an upward bound of just over 85k
> records.
In that case the result is written to a temporary file. This is a
limitation of H2, there is a feature request to fix that ("Server side
cursors") but I can't tell you when it will be implemented.
> I'm guessing at this point the max memory rows at 50000,
> causing the last 35k rows to be buffered to the temporary file would
> be the real issue... Would their be memory/performance issues if I
> raised the max memory rows to 100k?
I don't know how much memory it would use. You would need to try.
Regards,
Thomas
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en
-~----------~----~----~----~------~----~------~--~---
