Sorry - generally the sorts will be on one column - but they may choose at a later time to sort by another column. They will (but rarely - sort by two or more columns at the same time).
On 26 November 2012 14:20, Clemens Ladisch <clem...@ladisch.de> wrote: > 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 > -- Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
