drh [Mon, 25 Aug 2014 20:11:52 +0000 (20:11 +0000)]
Allow CAST expressions and unary "+" operators to be used in the DEFAULT
argument of an ALTER TABLE ADD COLUMN and to be understand on the RHS of
range constraints interpreted by STAT3/4. This involves a rewrite of the
implementation of the CAST operator.
dan [Mon, 25 Aug 2014 18:29:38 +0000 (18:29 +0000)]
In cases where stat4 data is available but cannot be used because the rhs of a range constraint is too complex a expression, fall back to using the default estimates for number of rows scanned.
drh [Mon, 25 Aug 2014 11:20:27 +0000 (11:20 +0000)]
Change the name of the VdbeMemRelease() macro to VdbeMemReleaseExtern() to
more accurately reflect what it does. Performance enhancement to the
sqlite3VdbeMemRelease() function.
drh [Sat, 23 Aug 2014 18:17:19 +0000 (18:17 +0000)]
Make the implementation of the sqlite3_aggregate_context() interface faster
for second an subsequent invocations. This helps all aggregate functions to
perform better.
drh [Fri, 22 Aug 2014 23:33:03 +0000 (23:33 +0000)]
Another performance tweak: Split the sqlite3BtreeCursorHasMoved() routine
into two with the second routine named sqlite3BtreeCursorRestore(). The first
now only reports whether or not the cursor has moved and the second tries to
restore the cursor. This allows the sqlite3VdbeCursorMoveto() routine to be
refactored to avoid stack pointer movements, for a noticable performance gain.
drh [Fri, 22 Aug 2014 20:35:29 +0000 (20:35 +0000)]
Combine the pcacheAddToDirtyList() and pcacheRemoveFromDirtyList() routines
into a single pcacheManageDirtyList() routine. The resulting binary code is
slightly faster and a few bytes smaller.
drh [Thu, 21 Aug 2014 14:10:23 +0000 (14:10 +0000)]
Fix a faulty assert() statement. Add comments to clarify the behavior of
the sqlite3OpenTableAndIndices() routine in insert.c. Add test cases to
verify that the assert() statement is not firing inappropriately.
Ticket [369d57fb8e5ccdff06f1].
drh [Wed, 20 Aug 2014 23:38:07 +0000 (23:38 +0000)]
Enhancements to skip-scan such that it is operable when a middle column of
an index is skipped while the left-most column is constrained in the WHERE
clause.
drh [Tue, 19 Aug 2014 20:27:40 +0000 (20:27 +0000)]
Make sure the sqlite3_trace() callback is invoked, even if the prepared
statement was marked "expired" before it ever entered sqlite3_step().
Ticket [11d5aa455e0d98f3c1e6a08].
dan [Tue, 12 Aug 2014 13:38:52 +0000 (13:38 +0000)]
If SQLITE_TEST_REALLOC_STRESS is defined, extend the op-code array used by virtual-machine programs by one element at a time, instead of doubling its size with each realloc().
dan [Fri, 8 Aug 2014 16:52:28 +0000 (16:52 +0000)]
Because SQLite internally calculates query plan costs using a logarithmic scale, very large estimated sorting costs can cause all other estimated costs to be rounded down to zero. In these cases break ties between plans with the same total cost by comparing the costs with sorting excluded. This is an alternative fix for the same problem as addressed by [2af630c572].
drh [Fri, 8 Aug 2014 15:38:11 +0000 (15:38 +0000)]
The SQLITE_IOERR_BLOCKED extended error code is not longer used, so remove
assert() statements and documentation for that error code. Also make other
documentation improvements.
drh [Thu, 7 Aug 2014 20:42:33 +0000 (20:42 +0000)]
When the estimated sorting cost overwhelms the estimated lookup cost, ensure
that lookup costs are still taken into account when selecting a lookup
algorithm.
drh [Thu, 7 Aug 2014 16:50:00 +0000 (16:50 +0000)]
When the estimated cost to do a sort overwhelms the estimated cost to do
individual table lookups, make sure that the table lookup costs are still
taken into consideration when selecting the lookup algorithm.
drh [Wed, 6 Aug 2014 00:29:06 +0000 (00:29 +0000)]
A simpler fix for ticket [3a88d85f36704eebe1] - one that uses less code.
The error message is not quite as good, but as this error has apparently
not previously occurred in over 8 years of heavy use, that is not seen as
a serious problem.
drh [Tue, 5 Aug 2014 19:16:22 +0000 (19:16 +0000)]
Add the ability to evaluate IN operators as a sequence of comparisons as
an alternative to the long-standing algorithm of building a lookup table.
Use the new implementation in circumstances where it is likely to be faster,
such as when the RHS of the IN changes between successive evaluations.
drh [Mon, 4 Aug 2014 21:26:58 +0000 (21:26 +0000)]
Part of the change in the previous check-in was incorrect and can result
in an incorrect UPDATE for WITHOUT ROWID tables. This check-in fixes the
problem.
drh [Sat, 2 Aug 2014 21:03:33 +0000 (21:03 +0000)]
Enhancements to the code generator for the IN operator that result in much
faster queries in some cases, for example when the RHS of the IN operator
changes for each row of a large table scan.
drh [Fri, 1 Aug 2014 18:00:24 +0000 (18:00 +0000)]
Remove an unnecessary OP_Null in the IN-operator logic. Attempt to clarify
comments explaining the IN-operator code, though it is not clear that the
comments are correct even yet - more work to be done.
drh [Fri, 1 Aug 2014 15:51:36 +0000 (15:51 +0000)]
Clean up the IN operator code generation logic to make it easier to reason
about. In the process, improve code generation to omit some unused OP_Null
operations.
drh [Fri, 1 Aug 2014 15:34:36 +0000 (15:34 +0000)]
The idea of coding IN operator with a short list on the RHS as an OR expression
turns out to be helpful. If the list is of length 1 or 2, the OR expression
is very slightly faster, but the ephemeral table approach is clearly better for
all list lengths greater than 2. Better to keep the code simple.