Documentation Source Text

  <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'>

  <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'>

<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

<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

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:

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: