Documentation Source Text

Check-in [735ffb4d2d]
Login

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

Overview
Comment:Remove obsolete statements from the EXPLAIN QUERY PLAN documentation.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 735ffb4d2d2578c19d94d7304defc00a927f30e6
User & Date: drh 2017-02-04 14:45:16.793
Context
2017-02-04
15:16
Updates to the change log for 3.17.0. (check-in: 90822d4b15 user: drh tags: trunk)
14:45
Remove obsolete statements from the EXPLAIN QUERY PLAN documentation. (check-in: 735ffb4d2d user: drh tags: trunk)
2017-02-03
04:10
Clarify wording about PRAGMA synchronous=NORMAL and WAL mode. (check-in: 7660cac647 user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/eqp.in.
︙︙
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96

^(<codeblock>
    sqlite&gt; EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1; 
    0|0|0|SCAN TABLE t1
</codeblock>)^

<p>
  The example above shows
  SQLite estimating that the full-table scan will visit approximately 
  100,000 records. If the query were able to use an index, then the 
  SCAN/SEARCH record would include the name of the index and, for a
  SEARCH record, an indication of how the subset of rows visited is
  identified. For example:
^(<codeblock>
    sqlite&gt; CREATE INDEX i1 ON t1(a);
    sqlite&gt; EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1;
    0|0|0|SEARCH TABLE t1 USING INDEX i1
</codeblock>)^

<p>
  The previous example, SQLite uses index "i1" to optimize
  a WHERE clause term of the form (a=?) - in this case "a=1". SQLite 
  estimates that about 10 records will match the "a=1" term.
  The previous example could not use a [covering index], but the following
  example can, and that fact is reflected in the output:
^(<codeblock>
    sqlite&gt; CREATE INDEX i2 ON t1(a, b);
    sqlite&gt; EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1; 
    0|0|0|SEARCH TABLE t1 USING COVERING INDEX i2 (a=?)
</codeblock>)^








|
|











|
<








68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

89
90
91
92
93
94
95

^(<codeblock>
    sqlite&gt; EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1; 
    0|0|0|SCAN TABLE t1
</codeblock>)^

<p>
  The example above shows
  SQLite picking full-table scan will visit all rows in the table.
  If the query were able to use an index, then the 
  SCAN/SEARCH record would include the name of the index and, for a
  SEARCH record, an indication of how the subset of rows visited is
  identified. For example:
^(<codeblock>
    sqlite&gt; CREATE INDEX i1 ON t1(a);
    sqlite&gt; EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1;
    0|0|0|SEARCH TABLE t1 USING INDEX i1
</codeblock>)^

<p>
  The previous example, SQLite uses index "i1" to optimize
  a WHERE clause term of the form (a=?) - in this case "a=1".

  The previous example could not use a [covering index], but the following
  example can, and that fact is reflected in the output:
^(<codeblock>
    sqlite&gt; CREATE INDEX i2 ON t1(a, b);
    sqlite&gt; EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1; 
    0|0|0|SEARCH TABLE t1 USING COVERING INDEX i2 (a=?)
</codeblock>)^
︙︙