sqlite/test/fts2k.test
shess 06c69d2ed6 Buffer updates per-transaction rather than per-update. If lots of
updates happen within a single transaction, there was a lot of wasted
encode/decode overhead due to segment merges.  This code buffers
updates in memory and writes out larger level-0 segments.  It only
works when documents are presented in ascending order by docid.
Comparing a test set running 100 documents per transaction, the total
runtime is cut almost in half. (CVS 3751)

FossilOrigin-Name: 0229cba69698ab4b44f8583ef50a87c49422f8ec
2007-03-29 18:41:03 +00:00

84 lines
2.2 KiB
Plaintext

# 2007 March 9
#
# The author disclaims copyright to this source code.
#
#*************************************************************************
# This file implements regression tests for SQLite library. These
# make sure that inserted documents are visible to selects within the
# transaction.
#
# $Id: fts2k.test,v 1.1 2007/03/29 18:41:05 shess Exp $
#
set testdir [file dirname $argv0]
source $testdir/tester.tcl
# If SQLITE_ENABLE_FTS2 is defined, omit this file.
ifcapable !fts2 {
finish_test
return
}
db eval {
CREATE VIRTUAL TABLE t1 USING fts2(content);
INSERT INTO t1 (rowid, content) VALUES(1, "hello world");
INSERT INTO t1 (rowid, content) VALUES(2, "hello there");
INSERT INTO t1 (rowid, content) VALUES(3, "cruel world");
}
# Test that possibly-buffered inserts went through after commit.
do_test fts2k-1.1 {
execsql {
BEGIN TRANSACTION;
INSERT INTO t1 (rowid, content) VALUES(4, "false world");
INSERT INTO t1 (rowid, content) VALUES(5, "false door");
COMMIT TRANSACTION;
SELECT rowid FROM t1 WHERE t1 MATCH 'world';
}
} {1 3 4}
# Test that buffered inserts are seen by selects in the same
# transaction.
do_test fts2k-1.2 {
execsql {
BEGIN TRANSACTION;
INSERT INTO t1 (rowid, content) VALUES(6, "another world");
INSERT INTO t1 (rowid, content) VALUES(7, "another test");
SELECT rowid FROM t1 WHERE t1 MATCH 'world';
COMMIT TRANSACTION;
}
} {1 3 4 6}
# Test that buffered inserts are seen within a transaction. This is
# really the same test as 1.2.
do_test fts2k-1.3 {
execsql {
BEGIN TRANSACTION;
INSERT INTO t1 (rowid, content) VALUES(8, "second world");
INSERT INTO t1 (rowid, content) VALUES(9, "second sight");
SELECT rowid FROM t1 WHERE t1 MATCH 'world';
ROLLBACK TRANSACTION;
}
} {1 3 4 6 8}
# Double-check that the previous result doesn't persist past the
# rollback!
do_test fts2k-1.4 {
execsql {
SELECT rowid FROM t1 WHERE t1 MATCH 'world';
}
} {1 3 4 6}
# Test it all together.
do_test fts2k-1.5 {
execsql {
BEGIN TRANSACTION;
INSERT INTO t1 (rowid, content) VALUES(10, "second world");
INSERT INTO t1 (rowid, content) VALUES(11, "second sight");
ROLLBACK TRANSACTION;
SELECT rowid FROM t1 WHERE t1 MATCH 'world';
}
} {1 3 4 6}
finish_test