Thomas, I just wanted to reiterate, optimizing the OR case is very important. Our product uses 7 different RDBMS, and for large OR statements, I had to do the H2 code significantly differently (select (...) union all ...) in order to get reasonable performance. And this approach has its own problems -- the resulting statements are unwieldy to look at. So having OR's use indexing would be a really big deal.
Chris On Fri, Sep 12, 2008 at 9:59 AM, Thomas Mueller <[EMAIL PROTECTED]> wrote: > > Hi, > > Thanks for the great test case! With the setting h2.optimizeInJoin, > the result is: > > SELECT pk FROM t WHERE pk = 1; > SELECT pk FROM t WHERE pk IN (1, 1000000); > SELECT pk FROM t WHERE pk = 1 AND pk = 1000000; > -- 0 ms > > SELECT pk FROM t WHERE pk = 1 OR pk = 1000000; > -- 7484 ms (still no index is used) > > In the next release, I will enable h2.optimizeInJoin by default. > > 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 -~----------~----~----~----~------~----~------~--~---
