On 2015/01/15 23:18, Baruch Burstein wrote:
Hi,
If I have a table with an index, and INSERT or DELETE a large number of
rows in one statement, does sqlite stop to update the index for each
record, or is it smart enough to update the index just once for all the
changed records?
In a B-Tree Index this hardly matters much in terms of total time (it just sometimes feels a lot faster when you first insert then
index, but in reality the total time should not differ hugely unless you are inserting an insane amount of rows), but it is not a
question of being "smart" enough or not, it's a question of functionality - if the index is unique or primary (for instance), it
must fail immediately when a duplication occurs, not at the end. How would it accomplish this if it deferred indexing to after the
insertions took place?
The SQL's first and foremost responsibility is producing correct answers and strict enforcement of the DB designer's rules - only
after these are satisfied can an engine attempt optimization. This is why it is suggested sometimes that if the checking does not
matter to you during insertion, then build the index afterwards.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
