Merge changes to the query planner that strive to ensure that any index
usage that is a proper subset of some other index usage always has a slightly
higher cost.
check-in: 683dd379 user: drh tags: trunk

Use OP_Copy instead of OP_SCopy when moving results out of a subquery,
to prevent the subquery results from changing out from under the outer
query. Fix for ticket [98825a79ce1456]. Problem introduced
by check-in [1e64dd782a126f48d78].
check-in: d5513dfa user: drh tags: trunk

Use OP_Copy instead of OP_SCopy when moving results out of a subquery,
to prevent the subquery results from changing out from under the outer
query. Fix for ticket [98825a79ce1456]. Problem introduced
by check-in [1e64dd782a126f48d78].
check-in: ec6a0624 user: drh tags: branch-3.8.4

Add a big introductory comment to vdbesort.c explaining its operation at a
high level. Also adjust some symbolic names and fix other comment issues in
that file.
check-in: eef60f1b user: drh tags: threads

When sorting data for a CREATE INDEX statement in single-threaded mode, assume that keys are delivered to the sorter in primary key order. Also fix various comments that had fallen out of date.
check-in: 821d1ac4 user: dan tags: threads

Even if compile time option SQLITE_MAX_WORKER_THREADS is set to one or greater, set the default number of worker threads to zero. Distribute data more evenly between threads in sqlite3VdbeSorterWrite() to improve performance when sorting large amounts of data. Add new test file sort2.test.
check-in: 643c86a0 user: dan tags: threads

Enhance the sqlite3VdbeRecordCompare() routines so that if they encounter
database corruption, they will set the UnpackedRecord.isCorrupt field and
return 0. The sqlite3BtreeMovetoUnpacked() routine detects this and returns
SQLITE_CORRUPT, causing the corruption to be reported back to the top-level.
check-in: 7fa85eaa user: drh tags: trunk

Instead of allocating a single large buffer at the beginning of each sort operation, start with a small buffer and extend it using realloc() as required.
check-in: 81987c8c user: dan tags: orderby-planning

Minor cleanup of the code in the query planner that computes the costs
estimates for the various plans. There are no changes to the costs at this
time. But the code is slightly more readable now and that might facilitate
future enhancements.
check-in: 9b4d7226 user: drh tags: trunk

Use xFetch() to access temporary files in vdbesort.c. Use a single large allocation instead of many small allocations when accumulating records in vdbesort.c. This is an interim commit - it allocates a buffer the size of the page-cache every time data is sorted.
check-in: f4ac1bf2 user: dan tags: orderby-planning

Detect when a VdbeCursor is still pointing at a valid row but that row has
moved, and invalidated the return from prior sqlite3BtreeDataFetch() or
sqlite3BtreeKeyFetch() calls.
check-in: e6798871 user: drh tags: trunk

Cancel column-cache entries that are involved in a comparison operator since
the comparison might have forced an affinity change.
Originally proposed as a fix for ticket [a8a0d2996a], but later determined
to be incorrect.
Closed-Leaf
check-in: 0b95b7a8 user: drh tags: tkt-a8a0d2996a

Fix the ORDER BY optimization logic so that it will do a block-sort on
a partial DESC ORDER BY. This enhancement uncovered a memory leak in
pushUntoSorter() which is also fixed.
check-in: c36f7461 user: drh tags: trunk

Change the names of SRT_DistTable and SRT_Table used by CTE to more
meaningful SRT_DistFifo and SRT_Fifo, respectively. Simplify the
IgnorableOrderby() macro in the process.
check-in: 45d8cc67 user: drh tags: trunk

The "x IN (?)" optimization in check-ins [2ff3b25f40] and [e68b427afb] is
incorrect, as demonstrated by the in4-5.1 test case in this check-in.
The "COLLATE binary" that was being added to the RHS of IN was overriding
the implicit collating sequence of the LHS. This change defines the EP_Generic
expression node property that blocks all affinity or collating sequence
information in the expression subtree and adds that property to the expression
taken from RHS of the IN operator.
check-in: 2ea4a9f7 user: drh tags: trunk

Previous check-in is not quite correct. "x IN (?)" is not exactly the same
as "x==?" do to collation and affinity issues. The correct converstion should
be to "x==(+? COLLATE binary)". The current check-in fixes this problem and
provides test cases. Ticket [e39d032577df69]check-in: 2ff3b25f user: drh tags: trunk

Convert expressions of the form "X IN (?)" with exactly one value on the
RHS of the IN into equality tests: "X=?". Add test cases to verify that
statements work correctly on this corner case.
Fix for ticket [e39d032577df6942].
check-in: e68b427a user: drh tags: trunk

Add an experimental fix to avoid attempting to mmap memory from an offset that is not a multiple of the system page size on systems with page sizes larger than 32KB.
check-in: 6f3a5c24 user: dan tags: shm-mapping-fix