Re: [sqlite] Performance...there must be a reason

[D. Richard Hipp]

Avner Levy wrote:
I've downloaded the latest src and compiled the new version 2.8.11 on 
Solaris 2.8 and tried to check the lock fix with the threadtest1.c.
The output was as followed:
=== 

2.testdb-4: command failed: INSERT INTO t2 VALUES(58,116,3364); - 
database schem
a has changed
=== 

If you change the "if" on line 147 to a "while", I think
it will clear this problem.
*** threadtest1.c   14 Jan 2004 03:32:38 -  1.1
--- threadtest1.c   21 Jan 2004 13:34:04 -
***
*** 144,150 
va_end(ap);
if( verbose ) printf("EXEC %s: %s\n", zFile, zSql);
rc = sqlite_exec(db, zSql, 0, 0, );
!   if( rc==SQLITE_SCHEMA ){
  if( zErrMsg ) free(zErrMsg);
  rc = sqlite_exec(db, zSql, 0, 0, );
}
--- 144,150 
va_end(ap);
if( verbose ) printf("EXEC %s: %s\n", zFile, zSql);
rc = sqlite_exec(db, zSql, 0, 0, );
!   while( rc==SQLITE_SCHEMA ){
  if( zErrMsg ) free(zErrMsg);
  rc = sqlite_exec(db, zSql, 0, 0, );
}




--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sqlite] Performance...there must be a reason

[Avner Levy]

I've downloaded the latest src and compiled the new version 2.8.11 on 
Solaris 2.8 and tried to check the lock fix with the threadtest1.c.
The output was as followed:
===
1.testdb-1: START
2.testdb-1: START
1.testdb-2: START
2.testdb-2: START
1.testdb-3: START
2.testdb-3: START
1.testdb-4: START
2.testdb-4: START
1.testdb-5: START
2.testdb-5: START
2.testdb-4: command failed: INSERT INTO t2 VALUES(58,116,3364); - 
database schem
a has changed
===

Another run gave:
===
1.testdb-1: START
2.testdb-1: START
1.testdb-2: START
2.testdb-2: START
1.testdb-3: START
2.testdb-3: START
1.testdb-4: START
2.testdb-4: START
1.testdb-5: START
2.testdb-5: START
Alarm clock
===
Did anyone tested this on Solaris ?
Your input is very important to me (I'm trying to find out if this 
version will solve the multi-threading database access problem).

Thanks in advance,
   Avner
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sqlite] Performance...there must be a reason

[Tim Anderson]

> -Original Message-
> From: Tim Anderson [mailto:[EMAIL PROTECTED] 
> Sent: 17 January 2004 22:45
> To: [EMAIL PROTECTED]
> Subject: [sqlite] Performance...there must be a reason

> What I can't work out is why. The same database is used. The 
> same Sqlite dll is used. The same pragmas are executed. The 
> compiler options are identical (unless I've missed a 
> directive lurking in the code somewhere).
> 
> Just wondering what I'm missing?

Solved. The reason is that the faster wrapper issues a BEGIN TRANSACTION
on app startup and leaves the transaction open until an update is
required. This makes hardly any difference on WinXP and an astonishing
difference on Win98.

It is no good surrounding the SELECT statement with BEGIN TRANSACTION
and ROLLBACK (or COMMIT); this takes just as long. You have to leave the
transaction open.

Logically a transaction is never necessary for a read-only SELECT. So in
a sense it should make no difference, and on WinXP that's the case. But
in my test installation of Win98 I get a huge speed-up.

Tim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]