Yes NULL - I underastand that ecvery coumn needs to be read, that is self evident, however my feeling (not tested) is that the process is much slower than it needs to be, i..e the process of creating an index on a column whos values are all NULL takes longer than just reading all of the columns - I have to admit to not testing/timimg this though, I'll have a go when time permits.
That does lead to another question. Is their a method of creating multiple indexes at the same time, e.g. create an index on each (or specified) column in a table in one pass - rather than do each column in turn. This would save on the overhead of reading the entire table for each column. On 24 November 2012 14:40, Clemens Ladisch <[email protected]> wrote: > Paul Sanderson wrote: > > Whilst building a new app I created an index on every column some of > which > > were empty. > > And with "empty", you mean that every value in that column is NULL? > > > The database is reasonably large (400K rows) and I notcied that > > it seems to take as long to create an index on a column in which all the > > rows are empty as it does on one in which all the rows are unique. > > SQLite still has to read all records to determine what the values are, > and to create the index with all these values and RowIDs. That these > values all happen to have the same value does not change the algorithm. > > > Regards, > Clemens > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
