If you're really sure that the index is correctly designed (WHERE criteria first, covers all SELECT columns, etc.) I won't argue with you.
If you do decide to go the table-scanning route, one thing that might speed things up for you is increasing your block size. Larger blocks means fewer blocks, fewer blocks means fewer reads... you get the idea. Probably won't make a huge difference given that you're dealing with a small number of rows, but if a tenth of second is important for you, then it might make some difference. -T On Tue, Oct 28, 2008 at 9:48 AM, Andrew Gatt <[EMAIL PROTECTED]> wrote: > Thomas Briggs wrote: >> How much slower is the index than your pre-populated table? If >> you're really comparing apples to apples it would be good to know how >> big the different is. >> >> If you post your schema and queries you'll probably get better >> advice. At that this I'm just guessing. >> >> -T >> >> > Not talking much, with about 1000 rows the difference is around 0.15 > seconds. But the user experience is the difference between instant and a > slight delay. I don't have any memory problems and so this seems like a > good idea. > > Andrew > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
