Re: [sqlite] Single row insert speeds

2007-12-04 Thread Mark Riehl
All - After reviewing some of my calculations, I realized I made a mistake and that the inserts didn't improve as much as I thought. I used the PRAGMA synchronouse = OFF and I'm averaging about 0.21 ms for an insert on a Core 2 Shuttle running Fedora 3. Here is the table I've defined: CREATE

Re: [sqlite] Single row insert speeds

2007-12-04 Thread drh
Mark Riehl [EMAIL PROTECTED] wrote: For testing, I've modified the the insert to look like this: char *insertStatement = PRAGMA synchronous=OFF;BEGIN;INSERT INTO sampleTable VALUES (\hostname\, \6\, \5.1.0\, \0\, \1708\, \1196303669.065335988998\,

RE: [sqlite] Single row insert speeds

2007-12-03 Thread Mike Marshall
What platform are you running on? Most of these sorts of issues that have come up before relate to the fact that SQLite is committing the data to the disc with each insert and has to ensure that the buffer has been written before it can process the next insert. IIRC there is a PRAGMA to switch

Re: [sqlite] Single row insert speeds

2007-12-03 Thread P Kishor
you would need to give more info about your db, the data, etc. On my Macbook Pro, I get 1000+ inserts a second for a random 100 byte string insert (that is, less than one per ms). That includes the time to generate the string, and is all in Perl, while I am listening to iTunes, and no funny pragma

Re: [sqlite] Single row insert speeds

2007-12-03 Thread drh
P Kishor [EMAIL PROTECTED] wrote: I get 1000+ inserts a second for a random 100 byte string insert ( I get 5+ inserts/sec on my Linux box. Insert speed is not the issue. It is COMMIT speed. At each commit, SQLite waits until all data is on oxide before continuing. That will typically

Re: [sqlite] Single row insert speeds

2007-12-03 Thread Günter Greschenz
hi, i am using a commit-thread: my application is starting a transaction with begin and is inserting a lot of data at random times, a thread is doing commit and begin every second (while locking the main app of course :-). this runs very fast and in case of crashes i loose only 1 second of

Re: [sqlite] Single row insert speeds

2007-12-03 Thread Mark Riehl
I'm running SQLite 3.1.13 under Fedora 3. Our real app is written in C++. The sample I wrote to debug the insert times is written in C (gcc 3.4.2). Here is the table I've defined: CREATE TABLE sampleTable ( logHost varchar(64) DEFAULT NULL, compId smallint(5) DEFAULT NULL, pid int(10)

Re: [sqlite] Single row insert speeds

2007-12-03 Thread P Kishor
On 12/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: P Kishor [EMAIL PROTECTED] wrote: I get 1000+ inserts a second for a random 100 byte string insert ( I get 5+ inserts/sec on my Linux box. turned off AutoCommit, turned off rand string generation, and lookee what I get... 200,000

Re: [sqlite] Single row insert speeds

2007-12-03 Thread Mark Riehl
I used the PRAGMA statement and turned off the synchronous option. It made a huge difference. Single inserts were ranging from 5 - 50 ms, now, they're at ~.04 ms. However, I guess there is a tradeoff between the safety of the synchronous operation (in case power is lost) versus the insert

Re: [sqlite] Single row insert speeds

2007-12-03 Thread P Kishor
On 12/3/07, Mark Riehl [EMAIL PROTECTED] wrote: I used the PRAGMA statement and turned off the synchronous option. It made a huge difference. Single inserts were ranging from 5 - 50 ms, now, they're at ~.04 ms. However, I guess there is a tradeoff between the safety of the synchronous

Re: [sqlite] Single row insert speeds

2007-12-03 Thread John Stanton
A faster disk will give you better performance. A 15,000 rpm disk will give almost three times the performance of a 5,400 rpm one and retain the ACID mode. You could also queue your input and launch periodic Sqlite transactions to empty the queue. Mike Marshall wrote: What platform are

Re: [sqlite] Single row insert speeds

2007-12-03 Thread Ken
I have a few suggestions for you to try: 1. Use prepared statements. Do not free the statement, reset it and re-use that way you don't incure the parsing overhead for each statement. 2. Use bind variables in conjunction. Redesign to perform more than single row inserts into a