--- michael cuthbertson <[EMAIL PROTECTED]> wrote: > Thanks for the response, Joe. > Unfortunately, since I have no way of knowing a priori what the relative > number of returned > rows is (without doing another query), using the plus is not really a > work-around, it is > a "don't use indexes" rule. > I can't just arbitrarily assign the "plus" mark.
Why not? Of course you can. It is not difficult to dynamically generate SQL depending on various application-specific heuristics. Assuming that running ANALYZE does not help you, at program startup, or perhaps every N changes to the table, cache in application memory a histogram of row counts per date. If the number of rows per time1 date is roughly the same, then simply caching the min and max dates should be sufficient for your needs. At runtime when you want to perform the query determine if the date range is wide and will hit most rows in your table - if so, use the +time1 trick. And even if you guess wrong - what's the big deal - perhaps 20% slower query performance in your specific case. Have reasonable expectation of what optimizations SQLite can perform. It's only 200K of code. SQLite performance is only as good as your approach. > Also, no other index was used, despite the plus on the time1 column. And > 'order by' did not use the index. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
