A complete list of SQLite releases - in a single page is also available. A detailed history of every - check-in is available at - - http://www.sqlite.org/src/timeline.
- } - hd_close_aux - hd_enable_main 1 - incr nChng - if {$nChng==1 && [file exists $DEST/$filename]} { - file copy -force $DEST/$filename $DEST/releaselog/current.html - } - } -} +proc chng {date desc {options {}}} { + global nChng aChng + set aChng($nChng) [list $date $desc $options] + incr nChng +} + +chng {2013-09-03 (3.8.0.2)} { +A complete list of SQLite releases + in a single page is also available. A detailed history of every + check-in is available at + + http://www.sqlite.org/src/timeline.
+ } + hd_close_aux + hd_enable_main 1 + if {$nChng==0 && [file exists $DEST/$filename]} { + file copy -force $DEST/$filename $DEST/releaselog/current.html + } + } +} +
+ By default, "unicode61" also removes all diacritics from Latin script
+ characters. This behaviour can be overriden by adding the tokenizer argument
+ "remove_diacritics=0". For example:
+
+
As well as the built-in "simple", "porter" and (possibly) "icu" and "unicode61" tokenizers, ADDED pages/hp1.in Index: pages/hp1.in ================================================================== --- /dev/null +++ pages/hp1.in @@ -0,0 +1,5 @@ +
$txt" hd_puts "
SQLite [version 3.8.0.2] contains a one-line fix to a bug in the + new optimization that tries to omit unused LEFT JOINs from a query. +} + +newsitem {2013-08-29} {Release 3.8.0.1} { +
SQLite [version 3.8.0.1] fixes some obscure bugs that were uncovered by + users in the 3.8.0 release. Changes from 3.8.0 are minimal. +} newsitem {2013-08-26} {Release 3.8.0} { Do not fear the zero!
SQLite [version 3.8.0] might easily have been called "3.7.18" instead. Index: pages/queryplanner-ng.in ================================================================== --- pages/queryplanner-ng.in +++ pages/queryplanner-ng.in @@ -203,11 +203,11 @@
The problem of finding the best query plan is equivalent to finding a minimum-cost path through the graph that visits each node exactly once.
(Side note: The costs estimates in the TPC-H Q8 graph were computed -by the query planner in SQLite 3.7.16 and converted using a base-10 logarithm.) +by the query planner in SQLite 3.7.16 and converted using a natural logarithm.)
The presentation of the query planner problem above is a simplification. @@ -255,11 +255,11 @@ The general case involves a lot of extra complication, which for clarity is neglected in the remainder of this article.
Prior to version 3.8.0, SQLite always used the +
Prior to version 3.8.0, SQLite always used the "Nearest Neighbor" or "NN" heuristic when searching for the best query plan. The NN heuristic makes a single traversal of the graph, always choosing the lowest-cost arc as the next step. The NN heuristic works surprisingly well in most cases. And NN is fast, so that SQLite is able to quickly find good plans @@ -274,11 +274,11 @@ N1 is in the next inner loop, N2 is in the third loop, and so forth down to P which is in the inner-most loop. The shortest path through the graph (as found via exhaustive search) is P-L-O-C-N1-R-S-N2 with a cost of 27.38. The difference might not seem like much, but remember that -the costs are logarithmic, so the shortest path is nearly 14,000 times +the costs are logarithmic, so the shortest path is nearly 750 times faster than that path found using the NN heuristic.
One solution to this problem is to change SQLite to do an exhaustive search for the best path. But an exhaustive search requires time proportional to @@ -562,11 +562,11 @@
In the "without ANALYZE" case on the left, the NN algorithm chooses loop P (PLINK) as the outer loop because 4.9 is less than 5.2, resulting -in path P-T which is algorithm-1. NN only looks a the single best choice +in path P-T which is algorithm-1. NN only looks at the single best choice at each step so it completely misses the fact that 5.2+4.4 makes a slightly cheaper plan than 4.9+4.8. But the N3 algorithm keeps track of the 5 best paths for a 2-way join, so it ends up selecting path T-P because of its slightly lower overall cost. Path T-P is algorithm-2. @@ -588,11 +588,11 @@
Running [ANALYZE] on the repository database immediately fixed the performance problem. However, we want Fossil to be robust and to always work quickly regardless of whether or not its repository has been analyzed. -For this reason, the query was modify to use the CROSS JOIN operator +For this reason, the query was modified to use the CROSS JOIN operator instead of the plain JOIN operator. SQLite will not reorder the tables of a CROSS JOIN. This is a long-standing feature of SQLite that is specifically designed to allow knowledgeable programmers to enforce a particular loop nesting order. Once the join