Paul Sanderson wrote: > My software creates a large table containing anything between about 250K > and Millions of rows when first run, the indexes are created immediately > after the table is populated and the tables do not change afterwards. > > The reason for the indexes is that the data is then reviewed by a user and > each user will have a different end result in mind and so will be looking > at (lots of) different subsets of the data but will want pretty much > instant results, i.e. a few seconds not minutes. I have no idea which > columns, other than a few of the main columns, that they will need to do > selects and sorts on.
If they can doing sorts on more than one column, you need indexes for all combinations of those columns. (For n columns, that's "only" n! combinations. Database size might become an issue ...) > The size of the database is never an issue. Memory is unlikely to be an > issue. The initial processing time (data loading and indexing) is not an > issue. Then why not creating covering indexes for every combination of sort columns? (This is essentially the same as creating lots of sorted copies of the table.) Regards, Clemens _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
