Documentation Source Text

Check-in [137b4b6a0f]
Login

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: 137b4b6a0fb6f29ad1036a0aca3e49263c93e3006ac4513bef5557adb1537db0
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
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

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.