On 6 June 2018 at 07:14, Richard Hipp <d...@sqlite.org> wrote: > On 6/5/18, Stéphane Aulery <lk...@free.fr> wrote: > > Hello, > > > > The changelog of the last release [1] say at the point 13 : > > > > UPDATE avoids writing database pages that do not actually change. For > > example, "UPDATE t1 SET x=25 WHERE y=?" becomes a no-op if the value in > > column x is already 25. Similarly, when doing UPDATE on records that > > span multiple pages, only write the subset of pages that contain the > > changed value(s). > > > > --------------------------------------------------------------------- > > > > I can't find in [2] and [3] if this change implies that a trigger will > > be fired or not on a row where x is already 25. A trigger could act at a > > physical or logical level and this change is a physical enhancement. > > > > Can someone inform me please? > > The enhancement is a low-level b-tree thing where it does a memcmp() > and only writes the page back to disk if there are actual byte > changes. > > Triggers continue to fire as they always have. > > There is no change in behavior. This is a performance optimization only.
Does this affect the locking behaviour? ie. is upgrading to a RESERVED lock a side effect of the b-tree writing out pages? Hmmm I presume not, since UPDATE currently upgrades to a RESERVED lock regardless of whether any rows are modified. -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
