Thank you for pointing out the omitJournal argument to sqlite3BtreeFactory!
That's just what I was looking for.
By forcing omitJournal to 1 in all cases (thereby always turning off
journaling), I was able to increase the total speed of my application by a
factor of 2.5 over the speed I got by
TED]
> To: sqlite-users@sqlite.org
> Date: Fri, 11 Apr 2008 17:45:35 -0500
> Subject: Re: [sqlite] Any way to disable journaling & rollback?
>
> Holding commits with a timeout is a feasible solution. However, in my
> application it is somewhat complex to implement. Multipl
Phil,
Yes its complicated. Yes its doable! But if you want performance its going to
be a bit complicated.
Sqlite does not allow concurrent read/write even from multiple threads!
Step back a bit, I've answered the question: yes you may disable journalling.
But the real problem your having is
Holding commits with a timeout is a feasible solution. However, in my
application it is somewhat complex to implement. Multiple threads are
accessing the database, and read requests usually run in a different thread
than writes. I don't want reads to be blocked while a commit timeout waits,
so
PROTECTED] On Behalf Of Griggs, Donald
Sent: 11 April 2008 14:06
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Any way to disable journaling & rollback?
Regarding: " removing the call of FlushFileBuffers for each transaction
made my application run 20 times faster.&qu
Yes the OS buffers, my error..
My point was that a close happens when sqlite commits. Which means that the OS
will attempt to write the buffers to disk and in all likely hood some of the
buffers will make it to disk this is I/O. Then the file is deleted aka commit!
Regards,
Ken
"Jay A.
On Fri, Apr 11, 2008 at 09:08:04AM -0700, Ken scratched on the wall:
> Even with Synchronous = off
>
> Sqlite will flush its buffers upon the commit!
I'm not talking about SQLite's buffers, I'm talking about the
file-system driver of the operating system.
> As a "close" system call is
Even with Synchronous = off
Sqlite will flush its buffers upon the commit! As a "close" system call is
performed!
The next step is to Delete the file. :) (the commit point).
"Jay A. Kreibich" <[EMAIL PROTECTED]> wrote: On Fri, Apr 11, 2008 at 03:28:47PM
+0200, Martin Engelschalk
Phil,
Removing the journalling will certainly cause you lots of grief in the event of
a "crash"...
You could do the following,
The write code (inserts) will queue incoming data into an "array/storage
in memory etc..."
When the first row is captured set a timer.
When
On Fri, Apr 11, 2008 at 03:28:47PM +0200, Martin Engelschalk scratched on the
wall:
> Hello Donald,
>
> I don't think so: The journal files are not synchronized on SYNCHRONOUS
> = OFF, but they are still written, so transactions are still possible.
Yes, but if I understand the
: Re: [sqlite] Any way to disable journaling & rollback?
Hello Donald,
I don't think so: The journal files are not synchronized on SYNCHRONOUS
= OFF, but they are still written, so transactions are still possible.
Martin
Griggs, Donald wrote:
> Regarding: " removing the call of Flus
Hello Donald,
I don't think so: The journal files are not synchronized on SYNCHRONOUS
= OFF, but they are still written, so transactions are still possible.
Martin
Griggs, Donald wrote:
> Regarding: " removing the call of FlushFileBuffers for each transaction
> made my application run 20
Regarding: " removing the call of FlushFileBuffers for each transaction
made my application run 20 times faster."
Since you don't need the integrity protection that transactions afford,
would you not get the same performance gain using the standard source
and setting SYNCHRONOUS to zero?
This
> Do you know that the performance without doing anything special is
unacceptable?
If I do insertions of a test set of 2000 records using a BEGIN
TRANSACTION/COMMIT around each one, the speed is 20 times slower than doing
additions in a single transaction. I hacked the winSync routine and
Hi all,
i have the same requirements. I don't need transactions at all and do
not care if my databases become corrupt.
However, i follow the versions of sqlite and do not want to change the code.
Perhaps it is an idea to add something like "paragma
disable_transactions" some time in the future?
Yes this can be Done.
There are two approaches.
A. Modify the sqlite code. (ok for a one off but not very portable)
B. Write your own VFS driver. (portable and more as the author intended).
http://www.sqlite.org/34to35.html
The best situation is if you are starting with an empty DB.
Phil Sherrod wrote:
> I have an application that requires creating a database with about 50
> million records. Is there any way to turn off journaling and rollback
> during the creation? I am willing to sacrifice reliability for speed in this
> situation.
>
Do you know that the performance
I have an application that requires creating a database with about 50
million records. Is there any way to turn off journaling and rollback
during the creation? I am willing to sacrifice reliability for speed in this
situation.
___
sqlite-users
18 matches
Mail list logo
