On Fri, Apr 11, 2008 at 01:54:43PM -0700, Richard Klein scratched on the wall: > Jay A. Kreibich wrote: > >On Thu, Apr 10, 2008 at 05:58:59PM -0700, Richard Klein scratched on the > >wall: > > > >>My advice would be to try it and see. If table creation takes too long, > >>you can always remove the UNIQUE constraint, and then write a routine to > >>check the table for uniqueness after it's created. > > > > That "routine" could simply be creating an explicit unique index on > > the column after all the data is loaded. If the index can be > > created, you're good to go. > > > > This is still a slow process, but I know the creation of indexes on > > existing tables is one area the development team hopes to speed up. > > I'm not sure what the priority of that is, however. > > Wouldn't this take just as long as creating the index immediately after > creating the table, and then letting each INSERT update the index?
There are savings to be found when you have the whole set of indexes available to you, just as you get some savings from batching up INSERTs. If you have a large enough page cache, you might be able to do a substantial part of the sort in one disk pass. If the sorter has the whole set avaliable, there's also the issue of how you deal with disk management and what sorting algorithm is used. Current thought is that there is room for improvement: http://www.mail-archive.com/sqlite-users@sqlite.org/msg31481.html Although that obviously doesn't help in the here and now. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "'People who live in bamboo houses should not throw pandas.' Jesus said that." - "The Ninja", www.AskANinja.com, "Special Delivery 10: Pop!Tech 2006" _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
