drh [Tue, 28 May 2024 15:37:41 +0000 (15:37 +0000)]
For query planning purposes, assume every table holds at least 100
rows, as this seems to give better worst-case performance if the table row
count estimate turns out to be inaccurate. Park this change on a branch for
now and consider it for a future enhancement.
drh [Tue, 28 May 2024 12:41:11 +0000 (12:41 +0000)]
Increase the number of parallel paths in the query solver from 12 to 20.
In the .wheretrace output, sort the parallel paths in order of increasing
cost.
drh [Tue, 28 May 2024 00:16:52 +0000 (00:16 +0000)]
Improve the automatic-index decision such that no attempt is made to create
an automatic index on a column that is known to be non-selective because if
its use in other indexes that have been analyzed. See
[src:/tktview/8ff324e120|ticket 8ff324e120] and
[forum:/forumpost/b21c2101a559be0a|forum post b21c2101a559be0a].
drh [Mon, 27 May 2024 15:13:49 +0000 (15:13 +0000)]
Very small performance increase and size reduction by removing unnecessary
ALWAYS() macros from the btree balance logic and replacing them with
special initialization of CellArray and some assert()s.
drh [Mon, 27 May 2024 13:24:39 +0000 (13:24 +0000)]
For compatibility with PostgreSQL, when right-hand side of the ->> operator
is negative, it should index from the right side of the JSON array on the
left-hand side.
drh [Fri, 24 May 2024 23:44:48 +0000 (23:44 +0000)]
Ensure that queries like "SELECT func(a) FROM tab GROUP BY 1" only call the
func() function once per row. Fix for the issue described in
[forum:/forumpost/bf8f43aa522c2299|forum thread bf8f43aa522c2299].
drh [Fri, 24 May 2024 20:18:16 +0000 (20:18 +0000)]
When omitting result columns for the vector-IN optimization, make sure that
any result-set column references in both the ORDER BY clause and the
GROUP BY clause are updated appropriately.
drh [Thu, 23 May 2024 23:26:04 +0000 (23:26 +0000)]
Fix the window-function group_concat() so that it returns an empty string
if it has one or more empty string inputs. This fixes
a bug introduced by [c6da39115d3e2b0f] on 2019-03-26 (version 3.28.0) and
reported by [forum/forumpost/bf8f43aa522c2299|forum post bf8f43aa522c2299].
drh [Thu, 23 May 2024 15:05:57 +0000 (15:05 +0000)]
Merge various enhancements that were being held on a branch until after the
3.46.0 release. (1) Allow arbitrary expressions in the second argument to
the RAISE() function. (2) Performance optimization to the OP_OpenRead and
OP_OpenWrite bytecode operators. (3) Allow FTS5 tables to be dropped even if
the associated tokenizer is not available. (4) Performance optimizations in
FTS5. (5) Generate better bytecode to improve performance of ONEROW scans.
drh [Tue, 21 May 2024 11:11:29 +0000 (11:11 +0000)]
Fix the -> and ->> operators so that when the RHS is a string that looks like
a number, it is still treated as a string, because that is what PG does.
[forum:/forumpost/9e52cdfe15c3926e|Forum post 9e52cdfe15c3926e].
drh [Mon, 20 May 2024 17:52:35 +0000 (17:52 +0000)]
Improvements to the documentation of sqlite3_vtab_distinct(). Do not allow
sqlite3_vtab_distinct() to return 2 or 3 if the rowid column of the virtual
table is used, as doing so might lead to an incorrect answer.
drh [Sat, 18 May 2024 20:00:08 +0000 (20:00 +0000)]
Fix the definition of sqlite3_vtab_distinct() such that return codes 2 and
3 mean that all rows must be distinct over "colUsed" which is a superset of
"aOrderBy". Also, disallow return codes 2 and 3 if the rowid of the virtual
table is accessed.
dan [Fri, 17 May 2024 14:26:32 +0000 (14:26 +0000)]
Merge branches "fix-onerow-opt", "faster-openread", "fts5-delay-tokenizer" and "enhanced-raise", each containing minor enhancements prepared for 3.47, into this branch.
drh [Thu, 16 May 2024 15:57:42 +0000 (15:57 +0000)]
The sqlite3_declare_vtab() interface should return SQLITE_ERROR, not
SQLITE_MISUSE when a nonsense SQL input is provided, for legacy compatibility.
[forum:/forumpost/4b875d7b2a|Forum post 4b875d7b2a].
drh [Thu, 16 May 2024 00:20:43 +0000 (00:20 +0000)]
Fix a case where an error in the ORDER BY clause of an aggregate function that is part of a trigger body might cause an assert() to fail in an ALTER TABLE command. dbsqlfuzz 899d9255555a07f1fe11a0bb51a2fe197b3150cd
drh [Wed, 15 May 2024 23:36:24 +0000 (23:36 +0000)]
Back out the assert() fixes from [a9443dbfbe25e588] and
[3afaeac56dff58db] (but keep the corresponding test cases) because they
are both made obsolete by the previous fix on this branch.
dan [Wed, 15 May 2024 21:38:04 +0000 (21:38 +0000)]
Fix a case where an error in the ORDER BY clause of an aggregate function that is part of a trigger body might cause an assert() to fail in an ALTER TABLE command.
dan [Wed, 15 May 2024 15:06:27 +0000 (15:06 +0000)]
If there is no data available for a field in a corrupted record, but the type is available, have the recovery extension substitute 0, 0.0, '' or X'' instead of a NULL value.
drh [Fri, 10 May 2024 18:24:15 +0000 (18:24 +0000)]
Fix aggregate function processing to correctly deal with OOMs inside of
sqlite3ParserAddCleanup().
(dbsqlfuzz b2d11ca70e55ee8bde48ae0b53fa3e9355812f95).
Also add improved testing support by causing sqlite3FaultSim(300) to
simulate an OOM inside of sqlite3ParserAddCleanup() and by adding
improved fault-sim support to the CLI.
drh [Fri, 10 May 2024 18:10:34 +0000 (18:10 +0000)]
The sqlite3FaultSim(300) error from [1e8863909ac369e5] must be treated as
an OOM, since it simulates an OOM. Also fix deferred deletion of Expr objects
from [a53bdd311c4154fd] so that it does not corrupt the AST if an OOM occurs.
stephan [Thu, 9 May 2024 18:00:14 +0000 (18:00 +0000)]
Reformulate a for-in loop to a for loop in wasm.xWrap() to work around a downstream framework-level misbehavior, as reported in [forum:b549992634b55104|forum post b549992634b55104].
dan [Mon, 6 May 2024 20:21:31 +0000 (20:21 +0000)]
When extracting links from sqlar archives, clobber any existing file or link, and do not call utimes() to set the timestamp - it looks through the link and operates on the target.
drh [Mon, 6 May 2024 19:04:46 +0000 (19:04 +0000)]
Avoid unnecessary recursion in sqlite3ExprDeleteNN(). This complicates the
code, but it is needed to prevent nuisance "stack overflow" reports from
OSSFuzz while it is running the latest ASAN.
drh [Sat, 4 May 2024 15:10:37 +0000 (15:10 +0000)]
Assume that an SQL function is able to return a subtype if any of its
arguments are SQL functions that are able to return subtypes. This closes
a corner-case hole in the patch at [ba789a7804ab96d8].
drh [Sat, 4 May 2024 15:04:45 +0000 (15:04 +0000)]
Assume that a function is able to return a subtype if either (1) it is itself
marked with SQLITE_RESULT_SUBTYPE, or (2) one of its arguments is a function
that is able to return a subtype. This check-in backs out the code changes
from the previous two on this same branch, but keeps the test cases from
the previous two.
drh [Sat, 4 May 2024 11:31:34 +0000 (11:31 +0000)]
Functions that pass through the sqlite3_value of one of their arguments must
also be marked as SQLITE_RESULT_SUBTYPE, in case one of their arguments has
a subtype.
drh [Fri, 3 May 2024 19:35:43 +0000 (19:35 +0000)]
The coalesce(), ifnull(), and iif() functions pass through subtype values
from their arguments, and hence need to have the SQLITE_RESULT_SUBTYPE flag
set. This fixes an corner-case for the patch at [ba789a7804ab96d8].
drh [Thu, 2 May 2024 12:14:31 +0000 (12:14 +0000)]
Fix the CREATE TABLE performance issue described by
[forum:/forumpost/4cf69794d9dfff7c|forum thread 4cf69794d9dfff7c] in two
different ways: (1) Omit the call to PRAGMA integrity_check('X') that was
being done after CREATE TABLE "X" because the result was being ignored and
the integrity_check was not doing anything other than burning CPU cycles.
(2) Do not interpret the argument to PRAGMA integrity_check as a number if it
is in fact a string that looks like a number.
drh [Thu, 2 May 2024 11:52:31 +0000 (11:52 +0000)]
Do not accept a string that looks like a number used as an argument to
PRAGMA integrity_check as a number. Treat it as a table name that just
happens to look like a number.
drh [Thu, 2 May 2024 11:51:26 +0000 (11:51 +0000)]
Omit the OP_SqlExec to "PRAGMA integrity_check" added by [348fa7aaf7958b3f]
because it is a no-op. Even if the integrity_check failes, the CREATE TABLE
is stull successful. The OP_SqlExec just burns CPU cycles for no reason.
Fix issues in [/info/1e227ad9f413227f|LIMIT/OFFSET support for virtual tables].
The first problem was reported by
[forum:/forumpost/c243b8f856|forum post c243b8f856]. That report prompted
an enhancement to the generate_series() (also included in this merge) which
in turn identified other similar issues.