Documentation Source Text

Check-in [6a23f5f429]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:More typo fixes.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 6a23f5f429622085749e334a7ea93547f28bd9760dc1f2087833e429b61a9d21
User & Date: drh 2018-01-09 19:47:24.822
Context
2018-01-09
20:05
Remove colloquialism to make the docs more understandable to non-native speakers. (check-in: 82f8d029ed user: drh tags: trunk)
19:47
More typo fixes. (check-in: 6a23f5f429 user: drh tags: trunk)
19:15
Fix typo in the rtreecheck() documentation. (check-in: 68f1e1944c user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/changes.in.
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
  <li> The optimization of using an index to quickly compute an
       aggregate min() or max() is extended to work with
       [indexes on expressions].
  <li> The decision of whether to implement a FROM-clause subquery
       as a co-routine or using query flattening now considers whether
       the result set of the outer query is "complex" (if it
       contains functions or expression subqueries).  A complex result
       set bias the decision toward the use of co-routines.
  <li> Avoiding query plans that use indexes with unknown
       collating functions.
  <li> Omit unused LEFT JOINs even if they are not the right-most joins
       of a query.
</ol>
<li> Other performance optimizations:
<ol type='a'>







|







48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
  <li> The optimization of using an index to quickly compute an
       aggregate min() or max() is extended to work with
       [indexes on expressions].
  <li> The decision of whether to implement a FROM-clause subquery
       as a co-routine or using query flattening now considers whether
       the result set of the outer query is "complex" (if it
       contains functions or expression subqueries).  A complex result
       set biases the decision toward the use of co-routines.
  <li> Avoiding query plans that use indexes with unknown
       collating functions.
  <li> Omit unused LEFT JOINs even if they are not the right-most joins
       of a query.
</ol>
<li> Other performance optimizations:
<ol type='a'>
Changes to pages/cli.in.
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
<tr><td> --sample&nbsp;PERCENT 
    <td> By default, the ".expert" command recommends indexes based on the
         query and database schema alone. This is similar to the way the
         [SQLite query planner] selects indexes for queries if the user has not
         run the [ANALYZE] command on the database to generate data
         distribution statistics. 
         <div style="margin-top:1ex">
         If this option is pass a non-zero argument, the ".expert" command
         generates similar data distribution statistics for all indexes
         considered based on PERCENT percent of the rows currently stored in
         each database table. For databases with unusual data distributions,
         this may lead to better index recommendations, particularly if the
         application intends to run ANALYZE.
         <div style="margin-top:1ex">
         For small databases and modern CPUs, there is usually no reason not







|







910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
<tr><td> --sample&nbsp;PERCENT 
    <td> By default, the ".expert" command recommends indexes based on the
         query and database schema alone. This is similar to the way the
         [SQLite query planner] selects indexes for queries if the user has not
         run the [ANALYZE] command on the database to generate data
         distribution statistics. 
         <div style="margin-top:1ex">
         If this option is passed a non-zero argument, the ".expert" command
         generates similar data distribution statistics for all indexes
         considered based on PERCENT percent of the rows currently stored in
         each database table. For databases with unusual data distributions,
         this may lead to better index recommendations, particularly if the
         application intends to run ANALYZE.
         <div style="margin-top:1ex">
         For small databases and modern CPUs, there is usually no reason not
Changes to pages/rtree.in.
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
Each entry in an R*Tree has a rowid.  The %_rowid shadow table maps entry
rowids to the node that contains that entry.

<tcl>hd_fragment rtreecheck rtreecheck()</tcl>
<h2>Integrity Check using the rtreecheck() SQL function</h2>

<p>The scalar SQL function rtreecheck(R) or rtreecheck(S,R) runs an
integrity check on the rtree table named R containing in database S.
The function returns a human-language description of any problems found,
or the string 'ok' if everything is ok.  Running rtreecheck() on an R*Tree
virtual table is similar to running [PRAGMA integrity_check] on a
database.

<p>Example: To verify that an R*Tree named "demo_index" is well-formed
and internally consistent, run:







|







595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
Each entry in an R*Tree has a rowid.  The %_rowid shadow table maps entry
rowids to the node that contains that entry.

<tcl>hd_fragment rtreecheck rtreecheck()</tcl>
<h2>Integrity Check using the rtreecheck() SQL function</h2>

<p>The scalar SQL function rtreecheck(R) or rtreecheck(S,R) runs an
integrity check on the rtree table named R contained within database S.
The function returns a human-language description of any problems found,
or the string 'ok' if everything is ok.  Running rtreecheck() on an R*Tree
virtual table is similar to running [PRAGMA integrity_check] on a
database.

<p>Example: To verify that an R*Tree named "demo_index" is well-formed
and internally consistent, run: