On Thu, May 7, 2009 at 2:23 PM, Brish <[email protected]> wrote: > > On May 7, 5:14 am, beaTunes Support <[email protected]> wrote: > > On May 6, 2009, at 23:35 , Brish wrote: > > Yes, Brish, for moving back and forth that would be good. > > But unfortunately the initial query still takes a very long time with > > h2. > > Most databases can iterate over results so they can return the first > few results immediately regardless of the result set size if the > result set isn't ordered or if the order can be resolved by an index. > > H2 runs the entire query then returns the results which causes all > large queries to be slow. >
As you say Brish, if the query is ordered, this problem arises on several other systems. For the usage model H2 seems designed for, the current implementation seems a reasonable design choice. One other thing to keep in mind is the gordian knot principle: if ordering makes the query slow, but the underdered query is fast, do the whole query unordered and sort the result set on the client side. Seriously, a million answers is not a big deal for most client frameworks. (see http://www.insideria.com/2008/08/i-accept-the-one-million-recor.html ) The more interesting case would be to use the unordered select to populate a temp table, then sort that. I don't *think* this would be a lot better under H2 (although under Oracle it is great), mainly because I don't think H2's indexing optimizes for bulk indexing. I could be wrong however. Chris --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
