Fix a compiler warning and an after-OOM memory leak.
Reopen the orderby-planning branch and merge in the latest trunk enhancements
and fixes.
Improved header comment on the vdbesort.c module.  No changes to code.
Changes to the way the planner calculates the costs of various table and index scans. Some test cases still failing.
When VDBE_PROFILE is enabled, ignore negative opcode times, which sometimes
occur, perhaps due to context swaps.
Make sure ORDER BY clauses on joins that involve virtual tables and that
have a DISTINCT clause work correctly.  This is a candidate fix for
ticket [388d01d4bb8f9].  Test cases for that ticket will be checked in
separately.
Store values loaded from the stat1 table as logarithmic values in memory.
Add test cases to ensure correct operation of joins with a virtual table
that include DISTINCT and ORDER BY clauses.  Verification for ticket
[388d01d4bb8f9].
If the user provides likelihood() data for a WHERE clause term used as part of an index key, have the planner use it when calculating the expected number of rows visited by the loop.
Avoid transfering records between tables unless the default values for all columns are the same. Fix for [f67b41381a].
Allow the xfer optimization to proceed if the DEFAULT on the very first
column of the two tables is different.  This is a refinement of the
fix for ticket [f67b41381a].
Update requirements marks to fix typos in the requirements text.
No changes to code.
Fix an sqlite3_stmt_status() problem caused by recent changs on this branch.
Fix an error in estimating of the number of rows visited by a range scan.
Modify internal function whereLoopAdjustCost() so that it does not prefer a skip-scan over a regular index scan even if the regular scan uses a subset of the WHERE terms used by the skip-scan.
Update test script analyze3.test to account for the fact that SQLite now prefers a full-table scan over a non-covering index scan that visits a large percentage of the table rows.
Add an extra column to a table in analyze9.test to give the planner a little more reason to select an index.
Update unordered.test to take into account for the fact that SQLite now prefers a full-table scan over a non-covering index scan that visits a large percentage of the table rows.
Add the sqlite3_rtree_query_callback() API to the RTree virtual table.
(Cherrypick from the sessions branch.)
The trunk assumes that an open range constraint on an indexed term (col>?) term matches 1/4 of the indexed rows, and that a closed constraint (col BETWEEN ? AND ?) matches 1/64. Change this branch to do the same.