On 4/14/08, Chris Tracy <[EMAIL PROTECTED]> wrote: > Err, > > Make that example table data: > > <...> > > 1167611400|89|7|34 > 1167611400|101|5|4 > 1167611400|147|9|14 > 1167611400|173|7|2 > 1167611400|195|8|1 > 1167611400|314|8|12 > 1167611400|347|6|48 > 1167611400|364|1|49 > > <snip> > > 1167615600|111|7|39 > 1167615600|155|2|8 > 1167615600|157|4|7 > 1167615600|220|4|47 > 1167615600|247|7|21 > 1167615600|261|8|30 > 1167615600|308|9|20 > > <...> > > As I'd originally said, the timestamps are inserted in ascending > order. (I just screwed up pasting my example values in the wrong order) > >
ok, but first, I don't really understand the following -- >SELECT * from bridge_table WHERE timestamp = <someval>; > >and almost immediately get back all the results I want, since they're >right next to each other in the db. However, the actual SELECT doesn't >return for almost 13 additional seconds, as the entire table is scanned >for other rows where timestamp might be <someval> Your first sentence above is that you "almost immediately get back all the results you want" then you go on to say that the "actual SELECT doesn't return for almost 13 additional seconds." So, what is it exactly that you "almost immediately get back"? _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
