On 23 Oct 2011, at 3:49pm, Fabian wrote: > So the only overhead for UNIQUE is that extra check? [snip]
Right. When doing an INSERT or UPDATE, it checks to see whether the value it's trying to add to the index already exists in the index. If it does, the result is an error. There is no difference in the file format used to store the index. > The difference between 9 and 156 seconds is too large for me. The original > author solved this by pre-sorting the data for the indexed column, which > made the difference 9 to 12 seconds (including the pre-sort), which is very > acceptable. > > So why does SQLite not pre-sort the data itself, when doing such large batch > inserts inside a transaction? In this example, the indexed column is a text column. The text fields could have been very long, and checking long text fields for uniqueness can involve comparing every byte. Nevertheless, I do not understand the results you quoted. I wonder whether some use of transactions would have vastly reduced the problem. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
