On 25 Nov 2012, at 1:29pm, Paul Sanderson <sandersonforens...@gmail.com> wrote:
> 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. In SQLite, all columns are in all indexes even if the column contains a NULL. NULL has a sorting order, and anything that does SELECT * FROM myTable ORDER BY myIndexedColumn still has to return all rows. > 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. It is very rare to need to index every column of a table. That is generally a sign that what you really want is some sort of three-column attribute store rather than a conventional database. You should know that any SELECT will only use either zero or one index: once you've used one index for sorting, the others are useless because they list rows in an unsorted order. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
