On 10/8/08, Igor Tandetnik <[EMAIL PROTECTED]> wrote: > "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. > > ..
Kudos! what a lovely and clear example. Many thanks, Puneet. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
