Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.
|Comment:||Clarification that the overwrite optimization does not affect the behavior of triggers.|
|Timelines:||family | ancestors | descendants | both | branch-3.24|
|Files:||files | file ages | folders|
|User & Date:||drh 2018-06-05 23:20:09|
|22:13||Fix typos in the compile.html page. check-in: 10c05df9fb user: drh tags: branch-3.24|
|13:21||Use https for all internal hyperlinks. Leaf check-in: 59e5f9e3da user: drh tags: branch-3.24-https|
|23:20||Clarification that the overwrite optimization does not affect the behavior of triggers. check-in: 27b8057665 user: drh tags: branch-3.24|
|19:41||Add the upsert-clause.gif image. check-in: 7d927bcea1 user: drh tags: trunk|
Changes to pages/changes.in.
42 42 <li> Automatically intercepts the raw [EXPLAIN QUERY PLAN] 43 43 output and reformats it into an ASCII-art graph. 44 44 <li> Lines that begin with "#" and that are not in the middle of an 45 45 SQL statement are interpreted as comments. 46 46 <li> Added the --append option to the ".backup" command. 47 47 <li> Added the ".dbconfig" command. 48 48 <p><b>Performance:</b> 49 -<li> [UPDATE] avoids writing database pages that do not actually change. 50 - For example, "UPDATE t1 SET x=25 WHERE y=?" becomes a no-op if the 51 - value in column x is already 25. Similarly, 52 - when doing [UPDATE] on records that span multiple pages, only write 53 - the subset of pages that contain the changed value(s). 49 +<li> [UPDATE] avoids unnecessary low-level disk writes when the contents 50 + of the database file do not actually change. 51 + For example, "UPDATE t1 SET x=25 WHERE y=?" generates no extra 52 + disk I/O if the value in column x is already 25. Similarly, 53 + when doing [UPDATE] on records that span multiple pages, only 54 + the subset of pages that actually change are written to disk. 55 + This is a low-level performance optimization only and does not 56 + affect the behavior of TRIGGERs or other higher level SQL 57 + structures. 54 58 <li> Queries that use ORDER BY and LIMIT now try to avoid computing 55 59 rows that cannot possibly come in under the LIMIT. This can greatly 56 60 improve performance of ORDER BY LIMIT queries, especially when the 57 61 LIMIT is small relative to the number of unrestricted output rows. 58 62 <li> The [OR optimization] is allowed to proceed 59 63 even if the OR expression has also been converted into an IN 60 64 expression. Uses of the OR optimization are now also