> SQLite has to read and parse the entire row anyway otherwise it would not be able to run triggers or re-write the row (update it). Of course it has to read the rows, but my point is that it in order to know whether a row was actually modified (as oppose to "affected"), it would have to *compare* N fields *unrelated to the WHERE clause*: ``` update t set a=1, b=2, ... 24 columns c..z omitted... where z=99; ``` Such an update would, in order for "changes" to know whether anything was *actually* modified, compare up to 25 columns (a..y) which are irrelevant for the WHERE clause (i.e. would not otherwise be compared). Granted, it would, on average, normally have to compare far fewer columns, but the fact remains that, computationally speaking, that comparison could, for arbitrarily large fields in arbitrary numbers of rows, be expensive and would necessarily apply to *every* update because sqlite cannot predict whether the client would eventually ask for the number of modified rows. Taking that into account, the behaviour of "changes" makes perfect sense (though the feature admittedly has an unfortunate name).