Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Merge changes from the 3.24 branch. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
137b4b6a0fb6f29ad1036a0aca3e4926 |
| User & Date: | drh 2018-07-23 11:02:03 |
Context
|
2018-07-23
| ||
| 11:17 | Merge changes from branch-3.24 check-in: 777501f7ed user: drh tags: trunk | |
| 11:02 | Merge changes from the 3.24 branch. check-in: 137b4b6a0f user: drh tags: trunk | |
| 11:00 | Further changes to the prosupport documentation. check-in: 00457c34b5 user: drh tags: trunk | |
| 10:53 | Changes to information on support packages. check-in: 5caed7a191 user: drh tags: branch-3.24 | |
Changes
Changes to pages/changes.in.
60 60 <li> Automatically intercepts the raw [EXPLAIN QUERY PLAN] 61 61 output and reformats it into an ASCII-art graph. 62 62 <li> Lines that begin with "#" and that are not in the middle of an 63 63 SQL statement are interpreted as comments. 64 64 <li> Added the --append option to the ".backup" command. 65 65 <li> Added the ".dbconfig" command. 66 66 <p><b>Performance:</b> 67 -<li> [UPDATE] avoids writing database pages that do not actually change. 68 - For example, "UPDATE t1 SET x=25 WHERE y=?" becomes a no-op if the 69 - value in column x is already 25. Similarly, 70 - when doing [UPDATE] on records that span multiple pages, only write 71 - the subset of pages that contain the changed value(s). 67 +<li> [UPDATE] avoids unnecessary low-level disk writes when the contents 68 + of the database file do not actually change. 69 + For example, "UPDATE t1 SET x=25 WHERE y=?" generates no extra 70 + disk I/O if the value in column x is already 25. Similarly, 71 + when doing [UPDATE] on records that span multiple pages, only 72 + the subset of pages that actually change are written to disk. 73 + This is a low-level performance optimization only and does not 74 + affect the behavior of TRIGGERs or other higher level SQL 75 + structures. 72 76 <li> Queries that use ORDER BY and LIMIT now try to avoid computing 73 77 rows that cannot possibly come in under the LIMIT. This can greatly 74 78 improve performance of ORDER BY LIMIT queries, especially when the 75 79 LIMIT is small relative to the number of unrestricted output rows. 76 80 <li> The [OR optimization] is allowed to proceed 77 81 even if the OR expression has also been converted into an IN 78 82 expression. Uses of the OR optimization are now also
Changes to pages/compile.in.
1033 1033 The default sorting procedure is to gather all information that will 1034 1034 ultimately be output into a "record" and pass that complete record 1035 1035 to the sorter. But in some cases, for example if some of the output 1036 1036 columns consists of large BLOB values, the size of the each record 1037 1037 can be large, which means that the sorter has to either use more memory, 1038 1038 and/or write more content to temporary storage. 1039 1039 <p> 1040 - When SQLITE_ENABLE_SORTER_PREFERENCES is enabled, the records passed to 1040 + When SQLITE_ENABLE_SORTER_REFERENCES is enabled, the records passed to 1041 1041 the sorter often contain only a [ROWID] value. Such records are much 1042 1042 smaller. This means the sorter has much less "payload" to deal with and 1043 1043 can run faster. After sorting has occurred, the ROWID is used to look up 1044 1044 the output column values in the original table. That requires another 1045 1045 search into the table, and could potentially result in a slowdown. Or, 1046 1046 it might be a performance win, depending on how large the values are. 1047 1047 <p> 1048 - Even when the SQLITE_ENABLE_SORTER_PREFERENCES compile-time option is on, 1048 + Even when the SQLITE_ENABLE_SORTER_REFERENCES compile-time option is on, 1049 1049 sorter references are still disabled by default. To use sorter references, 1050 1050 the application must set a sorter reference size threshold using the 1051 1051 [sqlite3_config]([SQLITE_CONFIG_SORTERREF_SIZE]) interface at start-time. 1052 1052 <p> 1053 1053 Because the SQLite developers do not know whether the 1054 - SQLITE_ENABLE_SORTER_PERFERENCES option will help or hurt performance, 1054 + SQLITE_ENABLE_SORTER_REFERENCES option will help or hurt performance, 1055 1055 it is disabled by default at this time (2018-05-04). It might be enabled 1056 1056 by default in some future release, depending on what is learned about its 1057 - inpact on performance. 1057 + impact on performance. 1058 1058 } 1059 1059 1060 1060 COMPILE_OPTION {SQLITE_ENABLE_STMT_SCANSTATUS} { 1061 1061 This option enables the [sqlite3_stmt_scanstatus()] interface. The 1062 1062 [sqlite3_stmt_scanstatus()] interface is normally omitted from the build 1063 1063 because it imposes a small performance penalty, even on statements that 1064 1064 do not use the feature.
Changes to pages/lang.in.
3442 3442 3443 3443 <p>In this last example, the phonebook2 entry is only 3444 3444 updated if the validDate for the newly inserted value is 3445 3445 newer than the entry already in the table. If the table already 3446 3446 contains an entry with the same name and a current validDate, 3447 3447 then the WHERE clause causes the DO UPDATE to become a no-op. 3448 3448 3449 +<h3>Limitations</h3> 3450 + 3451 +<p>UPSERT does not currently work for [virtual tables]. 3452 + 3449 3453 3450 3454 <tcl> 3451 3455 ############################################################################## 3452 3456 Section {ON CONFLICT clause} conflict {{conflict clause} {ON CONFLICT}} 3453 3457 3454 3458 RecursiveBubbleDiagram conflict-clause 3455 3459 </tcl>
Changes to pages/vtab.in.
261 261 destructor for client data pointer. The module structure is what defines 262 262 the behavior of a virtual table. The module structure looks like this: 263 263 264 264 <codeblock> 265 265 struct sqlite3_module { 266 266 int iVersion; 267 267 int (*xCreate)(sqlite3*, void *pAux, 268 - int argc, char **argv, 268 + int argc, char *const*argv, 269 269 sqlite3_vtab **ppVTab, 270 270 char **pzErr); 271 271 int (*xConnect)(sqlite3*, void *pAux, 272 - int argc, char **argv, 272 + int argc, char *const*argv, 273 273 sqlite3_vtab **ppVTab, 274 274 char **pzErr); 275 275 int (*xBestIndex)(sqlite3_vtab *pVTab, sqlite3_index_info*); 276 276 int (*xDisconnect)(sqlite3_vtab *pVTab); 277 277 int (*xDestroy)(sqlite3_vtab *pVTab); 278 278 int (*xOpen)(sqlite3_vtab *pVTab, sqlite3_vtab_cursor **ppCursor); 279 279 int (*xClose)(sqlite3_vtab_cursor*); ................................................................................ 350 350 <h1>Virtual Table Methods</h1> 351 351 352 352 <tcl>hd_fragment xcreate {sqlite3_module.xCreate} {xCreate}</tcl> 353 353 <h2>The xCreate Method</h2> 354 354 355 355 <codeblock> 356 356 int (*xCreate)(sqlite3 *db, void *pAux, 357 - int argc, char **argv, 357 + int argc, char *const*argv, 358 358 sqlite3_vtab **ppVTab, 359 359 char **pzErr); 360 360 </codeblock> 361 361 362 362 <p>The xCreate method is called to create a new instance of a virtual table 363 363 in response to a [CREATE VIRTUAL TABLE] statement. 364 364 If the xCreate method is the same pointer as the [xConnect] method, then the ................................................................................ 549 549 550 550 <tcl>############################################################# xConnect 551 551 hd_fragment xconnect {sqlite3_module.xConnect} {xConnect}</tcl> 552 552 <h2>The xConnect Method</h2> 553 553 554 554 <codeblock> 555 555 int (*xConnect)(sqlite3*, void *pAux, 556 - int argc, char **argv, 556 + int argc, char *const*argv, 557 557 sqlite3_vtab **ppVTab, 558 558 char **pzErr); 559 559 </codeblock> 560 560 561 561 <p>The xConnect method is very similar to [xCreate]. 562 562 It has the same parameters and constructs a new [sqlite3_vtab] structure 563 563 just like xCreate.