"P Kishor" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Imagine a db where the column 'foo' that you are querying against has > a different value for every single row. What possible good an index > would do?
It would let you find a row with a specific value in this column in logN steps, as opposed to O(N) a full table scan would take. > The db would spend as much time looking through an index, > and then going back and looking through the db... well, ok, once it > has found the matching entry in the index, it would jump to the right > row in the db, but it won't gain anything. Think of an index at the end of a book. You need to find all pages in a book where a particular term occurs. You don't read the whole index sequentially: since the index is arranged in alphabetical order, you can quickly look up your term, then you can quickly look up those pages by their numbers. Database index works similarly. Now imagine a book written with only two words, say "yes" and "no" (yes, such a book would be a pretty boring read). Suppose it, too, has an index at the end. However, an entry for "yes" lists pretty much every page in the book (and so does an entry for "no"). If you need to list all pages that contain the word "yes" (together with, say, the number of words on this page, so that you couldn't cheat and use the index alone), it would be easier to just scan every page in the book, rather than going through the index and looking up each page number separately. Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
