Simon Slavin <slavins@...> writes: > Nevertheless, this is the way the problem should be solved according to the design of SQLite. What you are > doing is searching for NULL entries in a table. > The way you speed up a search is to create an index
I do not mind adding indexes to columns, which are searched by the user. But my C1 is for internal use and I do not really need to search it. All I need is to loop through all rows, perform some comparison, update row and commit it (I would prefer to commit immediately after updating each row instead of after entire update query is finished). So, in this particular case SQL is more of an obstacle. It would have been easier to have a low level API for looping and updating rows, like some simpler DB engines used to have. Or, as I wrote before, just commit on interrupt. > Is the increase in input/time really unacceptable to you ? > The only thing that should take longer is inserting the row > in the first place. Yes, this time is the most important. This is why I keep NULL in C1 - to make insertion as quick as possible. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
