blob: fab4c4ed4deca76146ae0dd1dee32506a601eaab (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
# 2015-01-05
#
# The author disclaims copyright to this source code. In place of
# a legal notice, here is a blessing:
#
# May you do good and not evil.
# May you find forgiveness for yourself and forgive others.
# May you share freely, never taking more than you give.
#
#***********************************************************************
#
# This file verifies that INSERT operations with a very large number of
# VALUE terms works and does not hit the SQLITE_LIMIT_COMPOUND_SELECT limit.
#
set testdir [file dirname $argv0]
source $testdir/tester.tcl
set testprefix selectG
# Do an INSERT with a VALUES clause that contains 100,000 entries. Verify
# that this insert happens quickly (in less than 10 seconds). Actually, the
# insert will normally happen in less than 0.5 seconds on a workstation, but
# we allow plenty of overhead for slower machines. The speed test checks
# for an O(N*N) inefficiency that was once in the code and that would make
# the insert run for over a minute.
#
do_test 100 {
set sql "CREATE TABLE t1(x);\nINSERT INTO t1(x) VALUES"
for {set i 1} {$i<100000} {incr i} {
append sql "($i),"
}
append sql "($i);"
set microsec [lindex [time {db eval $sql}] 0]
db eval {
SELECT count(x), sum(x), avg(x), $microsec<10000000 FROM t1;
}
} {100000 5000050000 50000.5 1}
# 2018-01-14. A 100K-entry VALUES clause within a scalar expression does
# not cause processor stack overflow.
#
do_test 110 {
set sql "SELECT (VALUES"
for {set i 1} {$i<100000} {incr i} {
append sql "($i),"
}
append sql "($i));"
db eval $sql
} {1}
# Only the left-most term of a multi-valued VALUES within a scalar
# expression is evaluated.
#
do_test 120 {
set n [llength [split [db eval "explain $sql"] \n]]
expr {$n<10}
} {1}
finish_test
|
