Hi, Chris, Regarding: "It seems to me (and I might be wrong) that since the values are already in the database in ascending order by timestamp that SQLite is able to find all the results quite quickly. ..."
To test this, I think you'd want to create a select for some of the most recent data (i.e. data at the tail of the database), perhaps after clearing cache. I suspect this will take the full table scan time to return any values. Two thoughts: 1). Easy. How bad is the extra 0.8 GByte cost of the index? At today's prices, it's only about 20 cents on ordinary 5" drives. (but maybe you're programming a cellphone) 2). Fancy. You could create your own sparse index table mapping a ROWID to say, every thousandth timestamp. Then you could create upper and lower ROWID bounds on any query based on timestamps. Maybe you import the records in batches already and can create the new table at the same time. This email and any attachments have been scanned for known viruses using multiple scanners. We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
