[sqlite] SQLite performance graph not updated + 3 typos

Hi The SQLite performance graph at https://www.sqlite.org/cpu.html has not been updated since SQLite-3.21 (currently release being SQLite-3.23). Was it forgotten, or is the graph updated only once in a while? Also here are 3 typos found at https://www.sqlite.org/cpu.html in the same sentence:

[sqlite] Sqlite performance on windows vs linux

On 1 Mar 2016, at 1:54pm, Alvi, Tariq wrote: > We have been using sqlite on a windows server for a while and the traffic has > been increasing steadily. Meaning incoming data volume(inserts) and user > queries(select) have both increased. I was wondering if there have been any > performance

[sqlite] Sqlite performance on windows vs linux

We have been using sqlite on a windows server for a while and the traffic has been increasing steadily. Meaning incoming data volume(inserts) and user queries(select) have both increased. I was wondering if there have been any performance comparisons between windows and linux using similar

Re: [sqlite] SQLite performance with NOR FLASH

On 26 Jun 2014, at 7:42am, Vivek Ranjan wrote: > Code looks like this: Thanks. I was wondering whether you called _step() with strange value but you're calling it with -1, which seems to be the best thing to do in your case. And I don't see anything else wrong with

Re: [sqlite] SQLite performance with NOR FLASH

Hello Simon, Code looks like this: /* move content */ sqlite3_backup *pBackup; pBackup = sqlite3_backup_init(destDBHandle, "main", sourceDBHandle, "main"); if(pBackup) { int sqlErrno; if ((sqlErrno = sqlite3_backup_step(pBackup, -1)) !=

Re: [sqlite] SQLite performance with NOR FLASH

On 25 Jun 2014, at 9:14pm, Vivek Ranjan wrote: > sqlite3_backup_init() > > sqlite3_backup_step() > > sqlite3_backup_finish() >

[sqlite] SQLite performance with NOR FLASH

Dear All, I am unsing SQLite on NOR Flash with Sqlite version 3.8.5 with default setting i.e. sector and page size. Writing to NOR Flash taken around 10 seconds ( SQLite file size of 400KB, which is somehow not acceptable). Upon inserting additional debug prints, I found that since I use the

Re: [sqlite] sqlite performance with large and multiple attached databases

On 30 Mar 2010, at 9:02am, Akbar Syed wrote: > Unfortunately, I could not think about any other option than to keep > the devices attached all the time. I hope you don't have to handle many attachable devices, because SQLite can't handle more than 30 simultaneous ATTACHes. See section 11 of

[sqlite] sqlite performance with large and multiple attached databases

>>Make one big 'working' database by reading all the data from the databases on >>the independent devices and putting it into one big table. Once you have >>sucked out the data you can disconnect from the device. Then do all your >>enquiries on this big table. There's a special convenient

Re: [sqlite] sqlite performance with large and multiple attached databases

On 26 Mar 2010, at 10:47am, Akbar Syed wrote: > Unfortunately, my application restricts me to use independent > databases than to a single database > as each database exists on a different device and contains the info of > that device in the database. > Multiple devices are allowed to connect

[sqlite] sqlite performance with large and multiple attached databases

Hello, >>If you want to improve utilization memory, just put everything in one >> database. Each attached database in each connection has its own cache. >> With that many data sources you're going to get a very uneven distribution >> of cache utilization, and very high worst-case usage.

Re: [sqlite] sqlite performance with large and multiple attached databases

On Thu, Mar 25, 2010 at 05:22:04PM +0100, Akbar Syed scratched on the wall: > I have been trying to improve the performance and memory usage for my > application whereby i have maximum of 30 databases attached. In total I have > 31 databases with 30 databases attached to the first one. Each

[sqlite] sqlite performance with large and multiple attached databases

I have been trying to improve the performance and memory usage for my application whereby i have maximum of 30 databases attached. In total I have 31 databases with 30 databases attached to the first one. Each database has a single table with approx 65 columns and the records in each table may go

Re: [sqlite] SQLite performance with lots of data

On 5 Oct 2009, at 8:02am, Keith Roberts wrote: > On Sun, 4 Oct 2009, Simon Slavin wrote: > >> But note that the fields of the row are stored in (more or less) a >> list. So accessing the 20th column takes twice (-ish) as long as >> accessing the 10th column. If you make a table with 100

Re: [sqlite] SQLite performance with lots of data

On Sun, 4 Oct 2009, Simon Slavin wrote: > To: General Discussion of SQLite Database <sqlite-users@sqlite.org> > From: Simon Slavin <slav...@hearsay.demon.co.uk> > Subject: Re: [sqlite] SQLite performance with lots of data > > > On 4 Oct 2009, at 6:11pm, Cory Ne

Re: [sqlite] SQLite performance with lots of data

On 4 Oct 2009, at 6:11pm, Cory Nelson wrote: > On Fri, Oct 2, 2009 at 12:34 PM, Cory Nelson > wrote: >> On Fri, Oct 2, 2009 at 9:45 AM, Francisc Romano >> wrote: >>> Wow. I did not expect such a quick answer... >>> Is there somewhere I can read exactly

Re: [sqlite] SQLite performance with lots of data

On Fri, Oct 2, 2009 at 12:34 PM, Cory Nelson wrote: > On Fri, Oct 2, 2009 at 9:45 AM, Francisc Romano wrote: >> Wow. I did not expect such a quick answer... >> Is there somewhere I can read exactly how fast and how big databases SQLite >> can take, please? >

Re: [sqlite] SQLite performance with lots of data

On Fri, Oct 2, 2009 at 9:45 AM, Francisc Romano wrote: > Wow. I did not expect such a quick answer... > Is there somewhere I can read exactly how fast and how big databases SQLite > can take, please? SQLite uses a b+tree internally, which is logarithmic in complexity. Every

Re: [sqlite] SQLite performance with lots of data

Very good idea! Thank you! ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite performance with lots of data

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Francisc Romano wrote: > how big databases SQLite can take, please? Someone told me recently they have 37GB and 66 million rows in their data set. Another user is using the virtual table functionality together with synthetic indices to optimise

Re: [sqlite] SQLite performance with lots of data

On Fri, Oct 2, 2009 at 11:45 AM, Francisc Romano wrote: > Wow. I did not expect such a quick answer... > Is there somewhere I can read exactly how fast and how big databases SQLite > can take, please? See http://www.sqlite.org/limits.html for "how big." You will have to do

Re: [sqlite] SQLite performance with lots of data

Wow. I did not expect such a quick answer... Is there somewhere I can read exactly how fast and how big databases SQLite can take, please? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite performance with lots of data

On Fri, Oct 2, 2009 at 11:42 AM, Francisc Romano wrote: > Hello! > > I am not entirely certain this is the right way to proceed, but I haven't > been able to find the appropriate official SQLite forum (if one exists). > I want to create a rather complex AIR application that

[sqlite] SQLite performance with lots of data

Hello! I am not entirely certain this is the right way to proceed, but I haven't been able to find the appropriate official SQLite forum (if one exists). I want to create a rather complex AIR application that will have to deal with a massive database. My question is: Is SQLite capable of dealing

Re: [sqlite] SQlite performance on multi process env

Subject: Re: [sqlite] SQlite performance on multi process env Hello, Zhrahman, Regarding: "... kindly suggest how to properly have the database shared in memory among n number of processes. So they can execute select operatins(read only no update on teh database) effeci

Re: [sqlite] SQlite performance on multi process env

On Thu, May 28, 2009 at 10:53:34AM -0700, zhrahman scratched on the wall: > > Few other info > I am running it on Linux. So to make the long story short, kindly suggest > how to properly have the database shared in memory among n number of > processes. You can't. ":memory:" databases cannot

Re: [sqlite] SQlite performance on multi process env

zhrahman wrote: > Few other info > I am running it on Linux. So to make the long story short, kindly suggest > how to properly have the database shared in memory among n number of > processes. So they can execute select operatins(read only no update on teh > database) effeciently. >

Re: [sqlite] SQlite performance on multi process env

Few other info I am running it on Linux. So to make the long story short, kindly suggest how to properly have the database shared in memory among n number of processes. So they can execute select operatins(read only no update on teh database) effeciently. -- View this message in context:

Re: [sqlite] SQlite performance on multi process env

So yes the hard disk is shared. I tried to even load the database in memory. It is still horribly slow. I want to understand this. If I load the database in memory how can I make the memory sharable among 100 processes. I am running in quad core environement. So my goal here is to load the

Re: [sqlite] SQlite performance on multi process env

the hard disk is shared so it is a critical resource,as well as 100 processes doesn't seem realistic on a single processor, dual core or not. so I can understand your result, I find even them not too bad ... Cheers, Sylvain On Thu, May 28, 2009 at 12:38 AM, zhrahman

[sqlite] SQlite performance on multi process env

I am doing a simple test on sqlite where in step one, I just write 10,000 records on a simple database having three fileds. In step 2, after the write is done, I want 100 process reading from the database and doing simple SQLs, no update on the databse just simple select read operations. I am

[sqlite] sqlite performance issues on Linux running on MIPS (BIG ENDIAN)

Hi, I am planning to use sqlite in an application program. The application will be running in Linux environment on MIPS processor (BIG ENDIAN). Are there any sqlite performance issues when running on MIPS processor with Linux as the OS. In particular are there any issues regarding non-aligned

[sqlite] sqlite performance tuning and optimization

I am using SQLIte3 database and my query is running slow sometimes,sometimes it runs fast. Is there any sqlite Profiler available just like SQL Profiler for SQL server? My query looks like "SELECT ID, EventClassName, EventClassRef, TransitionTime, Message, MonitoredRef,

Re: [sqlite] SQLite performance on select/update with 11GB database file

On Wed, 08 Apr 2009 23:17:02 +0200, Florian Nigsch wrote: >Hi all, > >I have been trying to implement a couple of things in SQLite because I >only need it for myself (so no concurrency issues here). > >I am working on Arch Linux (uname: 2.6.28-ARCH #1 SMP PREEMPT Sun Mar >8

[sqlite] SQLite performance on select/update with 11GB database file

Hi all, I have been trying to implement a couple of things in SQLite because I only need it for myself (so no concurrency issues here). I am working on Arch Linux (uname: 2.6.28-ARCH #1 SMP PREEMPT Sun Mar 8 10:18:28 UTC 2009 i686 Intel(R) Xeon(TM) CPU 3.40GHz). I have a flat text file

Re: [sqlite] SQLite performance woe

at the schema output. Daniel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Griggs, Donald Sent: Wednesday, December 03, 2008 3:51 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLite performance woe Hi again, Daniel, So I guess you're

Re: [sqlite] SQLite performance woe

Hi again, Daniel, So I guess you're still having certain queries that take about 200x longer than with your custom code, right? There's nothing magical about sqlite, so it's not surprizing that code customized for an application can outperform a generalized sql engine, but a factor of 200 does

Re: [sqlite] SQLite performance woe

: Tuesday, December 02, 2008 5:06 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLite performance woe To efficiently execute the SQL "SELECT * FROM mytab WHERE myid = '1234'" you must have an index on the "myid" colunm. Each row has an index which u

Re: [sqlite] SQLite performance woe

, 2008 2:20 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] SQLite performance woe > > Databases work by using indices. A search for a row in a table of 1 > million rows goes from having to do as many as a million row reads to a > handful of index node access

Re: [sqlite] SQLite performance woe

nt: Tuesday, December 02, 2008 5:03 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLite performance woe Hello Donald & Others, I have primary keys set for each of the table but no indicies (that I am aware of) as I simply converted the data from our existing database system

Re: [sqlite] SQLite performance woe

-Original Message- Subject: Re: [sqlite] SQLite performance woe I maybe confused but indices sound similar to what I understand primary keys do, I already have primary keys on each table. Unless I'm mistaken as to what primary keys are? From your explanation I guess I'm slightly

Re: [sqlite] SQLite performance woe

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brown, Daniel Sent: Tuesday, December 02, 2008 5:03 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLite performance woe Hello Donald & Others, I have primary keys set for

Re: [sqlite] SQLite performance woe

] On Behalf Of John Stanton Sent: Tuesday, December 02, 2008 2:20 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLite performance woe Databases work by using indices. A search for a row in a table of 1 million rows goes from having to do as many as a million row reads

Re: [sqlite] SQLite performance woe

t; Daniel > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Griggs, Donald > Sent: Tuesday, December 02, 2008 9:52 AM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] SQLite performance woe > > Hi Daniel

Re: [sqlite] SQLite performance woe

sion of SQLite Database Subject: Re: [sqlite] SQLite performance woe Hi Daniel, Regarding: "What I'd like to know is if there is anything we can do with our queries, SQLite set-up or library configuration to improve the speed? " Unless indicies would be inappropriate, did you mentio

Re: [sqlite] SQLite performance woe

Hi Daniel, Regarding: "What I'd like to know is if there is anything we can do with our queries, SQLite set-up or library configuration to improve the speed? " Unless indicies would be inappropriate, did you mention whether you've defined any indicies and does EXPLAIN QUERY PLAN show

Re: [sqlite] SQLite performance woe

> > I am not using the amalgamation version of the source as I > have our my > VFS implementations for two of the platforms I work with > based on the > original win_os.c VFS and the amalgamation does not provide > the > necessary header files (os_common.h and sqliteInt.h) to > make VFS >

Re: [sqlite] SQLite performance woe

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brown, Daniel wrote: > I am not using the amalgamation version of the source as I have our my > VFS implementations for two of the platforms I work with based on the > original win_os.c VFS and the amalgamation does not provide the > necessary header

[sqlite] SQLite performance woe

Good evening list, I have been profiling the performance of SQLite version 3.6.1 against my current custom (hacktastic) runtime database solution (which I am hoping to replace with SQLite) and I just got a nasty and unexpected result: SQLite is a lot slower! I am running SQLite completely in

Re: [sqlite] SQLite Performance

> SELECT * FROM tetragrams > WHERE word1 = 'x' AND word2||'' = 'y' > ORDER BY occs; Better as SELECT * FROM tetragrams WHERE word1 = 'x' AND +word2 = 'y' ORDER BY occs; See http://www.sqlite.org/optoverview.html section 6. Hugh

Re: [sqlite] SQLite Performance

On Wed, 2007-04-18 at 11:06 +0100, Alberto Simões wrote: > On 4/17/07, Alberto Simões <[EMAIL PROTECTED]> wrote: > > On 4/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > "=?ISO-8859-1?Q?Alberto_Sim=F5es?=" <[EMAIL PROTECTED]> wrote: > > > > > > > > Consider the following database schema:

Re: [sqlite] SQLite Performance

On 4/17/07, Alberto Simões <[EMAIL PROTECTED]> wrote: On 4/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > "=?ISO-8859-1?Q?Alberto_Sim=F5es?=" <[EMAIL PROTECTED]> wrote: > > > > Consider the following database schema: > > CREATE TABLE tetragrams (word1 INTEGER, word2 INTEGER, word3

Re: [sqlite] SQLite Performance

On 4/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: "=?ISO-8859-1?Q?Alberto_Sim=F5es?=" <[EMAIL PROTECTED]> wrote: > > Consider the following database schema: > CREATE TABLE tetragrams (word1 INTEGER, word2 INTEGER, word3 INTEGER, > word4 INTEGER, occs INTEGER, PRIMARY KEY (word1, word2,

Re: [sqlite] SQLite Performance

"=?ISO-8859-1?Q?Alberto_Sim=F5es?=" <[EMAIL PROTECTED]> wrote: > > Consider the following database schema: > CREATE TABLE tetragrams (word1 INTEGER, word2 INTEGER, word3 INTEGER, > word4 INTEGER, occs INTEGER, PRIMARY KEY (word1, word2, word3, > word4)); > CREATE INDEX tet_b ON tetragrams

Re: [sqlite] SQLite Performance

On Tue, 2007-04-17 at 11:53 +0100, Alberto Simões wrote: > Hi > > I've found SQLite faster than MySQL and Postgres for small/medium > databases. Now I have big ones and I really do not want to change, but > I have some performance issues. > > Consider the following database schema: > CREATE

[sqlite] SQLite Performance

Hi I've found SQLite faster than MySQL and Postgres for small/medium databases. Now I have big ones and I really do not want to change, but I have some performance issues. Consider the following database schema: CREATE TABLE tetragrams (word1 INTEGER, word2 INTEGER, word3 INTEGER, word4

Re: [sqlite] sqlite Performance

Dennis's insight is apt. Just as you would eliminate "common sub expressions" in your programs (or have an optimizer do it for you) it is a good idea to do the same with systems. Writing numbers in an endian agnostic manner can easily be done on your flat file. Dennis Cote wrote: Ken

Re: [sqlite] sqlite Performance

At 15:51 16/03/2007, you wrote: Dennis, Yes the data will be read later by down stream processing. I do have the option of either putting the data into sqlite at the start (when its read) or putting it into a flat file and then Later loading it into a sqlite db via a downstream job.

Re: [sqlite] sqlite Performance

Ken wrote: I do have the option of either putting the data into sqlite at the start (when its read) or putting it into a flat file and then Later loading it into a sqlite db via a downstream job. A great deal of the data columns are simple numeric values and thats where sqlite

Re: [sqlite] sqlite Performance

Dennis, Yes the data will be read later by down stream processing. I do have the option of either putting the data into sqlite at the start (when its read) or putting it into a flat file and then Later loading it into a sqlite db via a downstream job. A great deal of the data

Re: [sqlite] sqlite Performance

Ken wrote: This is a write only app. 100% insert. Ken, Why bother putting the data into a database if you are never going to read it back out? Other formats, such as a flat text file are much better for logs or archives. If, in fact, you will be reading the data at some point then

Re: [sqlite] sqlite Performance

Hi Ken, you can get the exact insert speed of the flatfile.dat: - dump your data into the flat file - create a virtual table implementation for your flat file http://www.sqlite.org/cvstrac/wiki?p=VirtualTables&1150734307 - and use it from SQLite http://www.sqlite.org/lang_createvtab.html

Re: [sqlite] sqlite Performance

Ken <[EMAIL PROTECTED]> wrote: > > When the DB is closed when in synchrounous mode, > is it then persistent at the OS level even from power failures etc? > You don't have to close the DB. All you have to do is commit. Before the commit finishes, all of your data is guaranteed to be on

Re: [sqlite] sqlite Performance

DRH, Thanks for your valuable insite. When the DB is closed when in synchrounous mode, is it then persistent at the OS level even from power failures etc? [EMAIL PROTECTED] wrote: Ken wrote: > > I should be able to run with synchronous=off. Since > the application maintains

Re: [sqlite] sqlite Performance

Tito, Its even better now! Synchronous=normal and No primary keys (except 1 table) for auto increment. real0m1.975s user0m1.436s sys 0m0.140s Vs flat file test case: real0m0.862s user0m0.228s sys 0m0.188s This is now very respectable. Thanks, Ken

RE: [sqlite] sqlite Performance

"Griggs, Donald" wrote on 03/15/2007 01:49:30 PM: > Regarding: > Creation of flat file takes 1.5 secs vs 3 seconds to create sqlite db. > Flat file is 13 MB, sqlite db is 11 MB. > > "Any ideas how to get the sqlite output timings to a more respectable > level would be appreciated. " > I

Re: [sqlite] sqlite Performance

Ken <[EMAIL PROTECTED]> wrote: > > I should be able to run with synchronous=off. Since > the application maintains state in a seperate DB elsewhere. > Just to clarify the implications where, if you run with synchronous=off and you take a power failure or an OS crash in the middle of a

Re: [sqlite] sqlite Performance

Tito, There are no indices built besides the default ones. Hmm maybe I should try this by dropping the primary Keys.. I'll give that a try as well, GOOD idea! The entire batch of inserts (about 8 tables) is done in a single transaction. As an Oracle DBA, I'm pretty familar with tuning.

RE: [sqlite] sqlite Performance

Donald, I set the PRAGMA synchronous= OFF and here are the results: real0m2.258s user0m1.736s sys 0m0.168s -- Pragma synchronous= NORMAL real0m2.395s user0m1.520s sys 0m0.128s Pragma synchronous= FULL real0m3.228s user

Re: [sqlite] sqlite Performance

Hello, IIRC (it was a while ago), one way to speed up insertion for large data sets is to drop the indexes, do the inserts (wrapped around a transaction) and then rebuild the indexes. For smaller data sets, the drop/rebuild indexes solution doesn't make sense because the time it takes to

Re: [sqlite] sqlite Performance

There are no free lunches. When Sqlite stores your data item it not only writes it into a linked list of pages in a file but also inserts at least on key into a B-Tree index. It does it quite efficiently so what you are seeing is the inevitable overhead of storing the data in a structured

Re: [sqlite] sqlite Performance

Scott, The whole job is wrapped in an explicit transaction. Variables are bound and statements prepared only once, using reset. This is a write only app. 100% insert. Ken Scott Hess <[EMAIL PROTECTED]> wrote: Are you using explicit transactions at all? If not, as a quick test,

RE: [sqlite] sqlite Performance

ok my bad for poor wording... I'll try with Synchronous off. I may also try disabling the journal file since I can easily recreate the data if it is not successful. Thanks, Ken "Griggs, Donald" <[EMAIL PROTECTED]> wrote: Regarding: Creation of flat file takes 1.5 secs vs 3 seconds to

Re: [sqlite] sqlite Performance

To answer your question: Yes I can use a flat file at this stage, but eventually it needs to be imported into some type of structure. So to that end I decided early on to use sqlite to write the data out. I was hoping for better performance. The raw I/O to read the data and process is

RE: [sqlite] sqlite Performance

Regarding: Creation of flat file takes 1.5 secs vs 3 seconds to create sqlite db. Flat file is 13 MB, sqlite db is 11 MB. "Any ideas how to get the sqlite output timings to a more respectable level would be appreciated. " I may be way off base if I'm not understanding correctly, but how can

Re: [sqlite] sqlite Performance

Ken wrote: I'm looking for suggestions on improving performance of my sqlite application. Here are system timings for a run where the sqlite db has been replaced with a flat file output. real 0m1.459s user0m0.276s sys 0m0.252s This is a run when using sqlite as the output

[sqlite] sqlite Performance

I'm looking for suggestions on improving performance of my sqlite application. Here are system timings for a run where the sqlite db has been replaced with a flat file output. real 0m1.459s user0m0.276s sys 0m0.252s This is a run when using sqlite as the output format. real

Re: [sqlite] sqlite performance, locking & threading

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerry Snyder wrote: > The wiki is there and open to all. > > I look forward to reading your additions to it. To be fair, only some of the documentation is in the wiki. The remainder is generated. For example you can't edit any of the pages listed

Re: [sqlite] sqlite performance, locking & threading

Emerson Clarke wrote: Fix the out of date documentation The wiki is there and open to all. I look forward to reading your additions to it. Gerry - To unsubscribe, send email to [EMAIL PROTECTED]

Re: [sqlite] sqlite performance, locking & threading

For anyone who is interested i have created a standalone test case which demonstrates the threading behaviour that i had, or as close as i can get it. Feel free to use the code for whatever purposes you see fit. It will compile on linux and windows, and comes with 4 versions of the sqlite

RE: [sqlite] sqlite performance, locking & threading

sqlite-users@sqlite.org > Subject: Re: [sqlite] sqlite performance, locking & threading > > > Roger Binns wrote: > > >>Im sorry for being so harsh, and i know im not winning any friends > >>here, > >> > >> > > > >So far noo

Re: [sqlite] sqlite performance, locking & threading

Bill King wrote: Roger Binns wrote: Im sorry for being so harsh, and i know im not winning any friends here, So far noone has agreed with you :-) This would be incorrect. The correct statement is "so far no one has vocally agreed with you". If people didn't agree, this whole once

Re: [sqlite] sqlite performance, locking & threading

Roger Binns wrote: Im sorry for being so harsh, and i know im not winning any friends here, So far noone has agreed with you :-) This would be incorrect. The correct statement is "so far no one has vocally agreed with you". If people didn't agree, this whole once a month people

Re: [sqlite] sqlite performance, locking & threadin

Ken, Thanks for you comments. I have coded and tested a module just like test_server.c and by disabling the safety checks i have also been able to code and test an example which uses a single connection, single transaction, single table with up to 50 threads doing insert/update/delete with no

Re: AW: [sqlite] sqlite performance, locking & threading

> not to spark a debate Although the majority of this thread is as clear as mud, it is still interesting, even for simple VBA programmers like me that have no chance (maybe via a VB6 ActiveX exe) to use multi-threading. RBS > Emerson, one posts to a forum like this to get help and other ideas,

Re: AW: [sqlite] sqlite performance, locking & threading

Can we please stop this thread? John Stanton wrote: Emerson, one posts to a forum like this to get help and other ideas, not to spark a debate. Many talented people gave you some of their time to help you solve your problem and one in particular gave you a well conceived and executed piece

Re: AW: [sqlite] sqlite performance, locking & threading

Emerson, one posts to a forum like this to get help and other ideas, not to spark a debate. Many talented people gave you some of their time to help you solve your problem and one in particular gave you a well conceived and executed piece of software free of charge. Appreciate their charity.

Re: [sqlite] sqlite performance, locking & threading

Emerson, I agree with you somewhat. Not 100% convinced but, I like you am a little dissapointed how sqlite handles "threadsafe" and multiple connections. Even in the "test_server.c" module is not "concurrent" As it serializes all processing to a single thread, this is not concurrent

Re: [sqlite] sqlite performance, locking & threading

Roger, Of course you can test threading behaviour, yes its not exactly repeatable but under most circumstances and with enough test cases you can catch the problems. I don't think sqlite is such a large and complicated piece of software that it would be impossible to reproduce such errors.

Re: [sqlite] sqlite performance, locking & threading

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emerson Clarke wrote: > I have to admit i am a little dissapointed. As the primary author of > the software i would have thought that you would have a good > understanding of what the thread safety characteristics of your own > api were. He does!

Re: [sqlite] sqlite performance, locking & threading

Richard, I have to admit i am a little dissapointed. As the primary author of the software i would have thought that you would have a good understanding of what the thread safety characteristics of your own api were. Suggesting that suppressing the safety checks will result in random and non

Re: [sqlite] sqlite performance, locking & threading

"Emerson Clarke" <[EMAIL PROTECTED]> wrote: > > The problem i had was with sqlite not being compatible with the simple > design that i wanted. I did try several alternate designs, but only > as a way of working around the problem i had with sqlite. It took a > long time but eventually i managed

Re: AW: [sqlite] sqlite performance, locking & threading

John, Um, alright then... But i think your preaching to the converted, simplifying things is what i always try to do. And not just when theres a problem If you followed the thread fully you would realise that there was never a problem with my design, though that didnt stop many people

Re: AW: [sqlite] sqlite performance, locking & threading

Clarke [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 3. Januar 2007 20:31 > An: sqlite-users@sqlite.org > Betreff: Re: [sqlite] sqlite performance, locking & threading > > Michael, > > Thanks for the advice. During the indexing process i need to select and > optionally

Re: AW: [sqlite] sqlite performance, locking & threading

> Michael > > -Ursprüngliche Nachricht- > Von: Emerson Clarke [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 3. Januar 2007 20:31 > An: sqlite-users@sqlite.org > Betreff: Re: [sqlite] sqlite performance, locking & threading > > Michael, > > Thanks fo

Re: [sqlite] sqlite performance, locking & threading

Bill, Thanks for the description, thats pretty much how i designed the index, but with a few modifications. The filesystem becomes the tree structure which is indexed by a hash of the original document url. It works like a big hashtable so its quite scalable. > Sorry if this has been

Re: AW: [sqlite] sqlite performance, locking & threading

] Gesendet: Mittwoch, 3. Januar 2007 20:31 An: sqlite-users@sqlite.org Betreff: Re: [sqlite] sqlite performance, locking & threading Michael, Thanks for the advice. During the indexing process i need to select and optionally insert records into a table so i cant ignore the outcomes. Basic

Re: [sqlite] sqlite performance, locking & threading

Emerson Clarke wrote: The indexing process works like this. 1.) Open a document and parse its contents. 2.) Look up records in the first database based on the contents of the document, updating records where appropriate and inserting new ones. 3.) Transforming the document based on what was

Re: [sqlite] sqlite performance, locking & threading

On Thu, Jan 04, 2007 at 12:50:01AM +, Emerson Clarke wrote: > My oppologies, your right that explanation had been given. OK. > But i didnt actually take it seriously, i guess i found it hard to > believe that it being the easier option was the only reason why this > limitation was in place.

Re: [sqlite] sqlite performance, locking & threading

Nicholas, My oppologies, your right that explanation had been given. But i didnt actually take it seriously, i guess i found it hard to believe that it being the easier option was the only reason why this limitation was in place. If this is the case, then surely the fix is simple. Given that

  1   2   3   >