On 12/8/2014 8:43 PM, Keith Medcalf wrote:
That is not a problem -- and I only fixed the where clause, not the set clause.
The data will be "hot" on the second access, so the overhead of the additional
access is negligible since CPU usage is negligible (even if it goes through all the
motions of cold access) compared to I/O usage -- given a large enough page cache in RAM
(so no I/O is required) to hold the pages involved in the tree traversals, of course.
It's not really about efficiency - it's about verbosity. Imagine that
you need to update not one but 10 fields in temp_table from the
corresponding row in some_table: now you need to repeat the same
condition 11 times. Imagine further that the condition is more
complicated, involving joins on several tables. Pretty soon, we are
talking one really long and convoluted query.
Yes, there are workarounds (a view; or REPLACE INTO may sometimes be
pressed into service). But I, for one, kinda miss UPDATE ... FROM.
--
Igor Tandetnik
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
