Hi,
As part of the Subversion 1.8.6 release we tried introducing some data in
the 'sqlitstat_stat1' table using the recommended approach for Sqlite 3.8.0+
compatibility to tell sqlite about our 'bad indexes':
[[
ANALYZE sqlite_master;
INSERT INTO "sqlite_stat1" VALUES
INSERT INTO
On Mon, Feb 10, 2014 at 9:02 PM, Richard Hipp wrote:
>
> Your work-arounds pending the patch release:
>
> (1) Do not compile with SQLITE_ENABLE_STAT3 or SQLITE_ENABLE_STAT4
> (2) Change your query so that it says "+moved_to IS NOT NULL" - add a
> unary "+" operator before every
Thanks for the bug report.
This was a real problem. It is now fixed on the SQLite trunk (
http://www.sqlite.org/src/info/c950d6c411). It will be a few days before
we can get a patch release (3.8.3.1) together.
Your work-arounds pending the patch release:
(1) Do not compile with
Ticket here: http://www.sqlite.org/src/info/4c86b126f2
The work-around until a fix is available is to avoid compiling with
SQLITE_ENABLE_STAT3 or SQLITE_ENABLE_STAT4.
On Mon, Feb 10, 2014 at 4:38 PM, Richard Hipp wrote:
> STAT3 should never change the answer. It should only
STAT3 should never change the answer. It should only help the answer to
appear faster. The fact that the queries gives different answers with and
without STAT3 clearly indicates a bug. We are working the problem now.
Thanks for providing an simplified test case.
On Mon, Feb 10, 2014 at 2:05
On Feb 10, 2014, at 8:05 PM, Bert Huijben wrote:
> As part of the Subversion 1.8.6 release we tried introducing some data in
> the 'sqlitstat_stat1' table using the recommended approach for Sqlite 3.8.0+
> compatibility to tell sqlite about our 'bad indexes’:
( Not
[Retrying with the user I subscribed with to avoid the moderation]
Hi,
As part of the Subversion 1.8.6 release we tried introducing some data in
the 'sqlitstat_stat1' table using the recommended approach for Sqlite 3.8.0+
compatibility to tell sqlite about our 'bad indexes':
[[
ANALYZE
7 matches
Mail list logo