Apparently I did something wrong the first time when I tried the exclusive
lock because now I don't see SQLite reading the file change counter
anymore. Sorry for that.
I did some performance measurement on an FTS index on Android and I see
some performance gain of around 5%. That is a nice gain bu
While tracking all the I/O that SQLite does I noticed that the same 16
bytes are read over and over again. After some investigation I found out
that it is reading the File change counter to see if another process has
changed the database.
As in this program there is only one read-only process that
I did some profiling with gprof to see why the query which does an extra
ordering on descending docid is (surprisingly) 100 times faster than the
normal query. As you can see in the results below is that the functions
fts3PoslistCopy and sqlite3Fts3GetVarint get called over more than 400
million ti
Hi,
I'm currently working on a project that makes use of the SQLite FTS
functionality (version 3.7.14) on a large data set of POI (point of
interest). Most of the time it works fine but I stumbled on a few queries
that take a lot of time to complete. It's confusing to me what actually is
going on
;conn)
{ sqlite3_close(self->conn); self->conn=NULL; }
Py_RETURN_NONE;
}
setting the pointers to the prepared statements to NULL for making
further new initializations possible.
Now this works - after some testing and eventual debugging of
update(
st be wrong. Thanks for this very fast answer !
Joost
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
see the uncommented rows for COMMIT_stmt and BEGIN_stmt.
Indeed performing these lines crashes the litelineup. Is it true, that
we must not finalize a statement prepared by
sqlite3_prepare_v2(self->conn, "COMMIT ;", -1, &self->COMMIT_stmt,
NULL);
or BEGIN IMMEDIATE ?
And i
7 matches
Mail list logo
