Re: [sqlite] Row Level Locking as in InnoDB

2013-11-11 Thread Raheel Gupta
Ok. Thank you for your explanation everyone and for being patient with me. I look forward to Sqlite4 in whatever features you implement :) On Mon, Nov 11, 2013 at 8:17 PM, Richard Hipp wrote: > On Mon, Nov 11, 2013 at 1:40 AM, Raheel Gupta wrote: > > > > > I guess a Row level locking could be

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-11 Thread Richard Hipp
On Mon, Nov 11, 2013 at 1:40 AM, Raheel Gupta wrote: > > I guess a Row level locking could be difficult but a Page Level locking > could be not that difficult. > In an anomaly-free system, page level locking is not difficult. The difficulty comes when you have to recover from an application cra

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-11 Thread RSmith
On 2013/11/11 08:40, Raheel Gupta wrote: I guess a Row level locking could be difficult but a Page Level locking could be not that difficult. ATM "db level locking" : If DB locked throw busy error In not locked lock db, let the writer do its thing For Page level locking (I think you could allo

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-10 Thread Sylvain Pointeau
Hello, If I would have one wish, it would not be the row level locking but the merge syntax, so usefulf to update, insert or update in 1 command (no insert or replace is not an equivalent), and in general it would be good to implement the sql 2003. Just a wish. Best regards, Sylvain Le lundi 11

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-10 Thread Raheel Gupta
@simon I guess a Row level locking could be difficult but a Page Level locking could be not that difficult. ATM "db level locking" : If DB locked throw busy error In not locked lock db, let the writer do its thing For Page level locking (I think you could allow something like) : Let writer write

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-10 Thread John McKown
Just a personal observation from the peanut gallery (my uninformed opinion). I like SQLite pretty much as is. When I use it, I want reliable (ACID), fast, and SQL compliant. I use SQLite more like an "embeded" or "single user" SQL engine. I don't use it for a really hairy data base application. Yes

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-10 Thread Simon Slavin
On 10 Nov 2013, at 12:05pm, Raheel Gupta wrote: >>> I can't think of any other single feature that would remove the "lite" > > I am not a database expert. If you say so, it must be the case. > But if there is a way to implement concurrent writers in SQLite maintaining > the "lite" in SQLite, I

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-10 Thread Howard Chu
Raheel Gupta wrote: Look at the performance difference between BDB and SQLite3 here http://symas.com/mdb/microbench/#sec1 I did, and I really cant comment on that. The results are of 2012 and its almost 2013. You should update the page with a newer result set. Or you could just download the c

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-10 Thread Raheel Gupta
>> Look at the performance difference between BDB and SQLite3 here http://symas.com/mdb/microbench/#sec1 I did, and I really cant comment on that. The results are of 2012 and its almost 2013. You should update the page with a newer result set. >> I can't think of any other single feature that wou

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-09 Thread Ryan Johnson
On 08/11/2013 5:07 AM, Raheel Gupta wrote: No. It's not even feature-frozen yet, as far as we know. And whenever it is, it's incredibly unlikely to have row level locking. Please add row-level locking if possible. I can't think of any other single feature that would remove the "lite" from sqli

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-08 Thread Howard Chu
Raheel Gupta wrote: Hi, You use BDB SQL or BDB KV ? I built BDB 6.0.20 with --enable-sql_compat It made a libsqlite3.so in the .libs folder which I linked with my QT C++ Application. You must try it with SQLightning too, https://gitorious.org/mdb/ sqlightning I tried to build it, but it sa

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-08 Thread Raheel Gupta
> > This is the BDB SQL doc I found. > > > http://docs.oracle.com/cd/E17076_02/html/bdb-sql/dbfeatures.html#bulkloading > > If you insert record in bulk, you can use PRAGMA TXN_BULK for optimization. > I tested TXN_BULK, still pretty slow. Nearly 2.4 times. Also the space wastage is pretty high. I

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-08 Thread Raheel Gupta
Hi, >> You use BDB SQL or BDB KV ? I built BDB 6.0.20 with --enable-sql_compat It made a libsqlite3.so in the .libs folder which I linked with my QT C++ Application. >> You must try it with SQLightning too, https://gitorious.org/mdb/ sqlightning I tried to build it, but it says lmdb.h missing. W

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-08 Thread Aris Setyawan
This is the BDB SQL doc I found. http://docs.oracle.com/cd/E17076_02/html/bdb-sql/dbfeatures.html#bulkloading If you insert record in bulk, you can use PRAGMA TXN_BULK for optimization. On 11/8/13, Aris Setyawan wrote: > You use BDB SQL or BDB KV ? > > You must try it with SQLightning too, ht

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-08 Thread Aris Setyawan
You use BDB SQL or BDB KV ? You must try it with SQLightning too, https://gitorious.org/mdb/sqlightning On 11/8/13, Aris Setyawan wrote: >> For a single threaded application BDB is very bad after I tested. >> It takes nearly 2.5 times the amount of time and CPU to do a transaction >> of >> 40MB

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-08 Thread Aris Setyawan
> For a single threaded application BDB is very bad after I tested. > It takes nearly 2.5 times the amount of time and CPU to do a transaction of > 40MB Data. E.g. If SQLIte did the 40MB data transaction (1 rows of 4 K) > in 1 second, BDB was taking 2.5 seconds and more CPU as well. I did this

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-08 Thread Raheel Gupta
>> No. It's not even feature-frozen yet, as far as we know. And whenever it is, it's incredibly unlikely to have row level locking. Please add row-level locking if possible. On Fri, Nov 8, 2013 at 12:03 AM, Simon Slavin wrote: > > On 7 Nov 2013, at 6:31pm, Raheel Gupta wrote: > > > Any idea w

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-08 Thread Raheel Gupta
>> If you have many core of processors [and big RAM], then I recommend BDB Sql over Sqlite. Because you can have many processes or threads to write to a database concurrently. For a single threaded application BDB is very bad after I tested. It takes nearly 2.5 times the amount of time and CPU to

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-07 Thread Simon Slavin
On 7 Nov 2013, at 6:31pm, Raheel Gupta wrote: > Any idea when will SQLite4 be released as stable ? No. It's not even feature-frozen yet, as far as we know. And whenever it is, it's incredibly unlikely to have row level locking. Simon. ___ sqlite-u

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-07 Thread Raheel Gupta
>> SQLite4 still in development phase. It is not production ready. Any idea when will SQLite4 be released as stable ? On Tue, Nov 5, 2013 at 8:20 AM, Howard Chu wrote: > Aris Setyawan wrote: > >> Hi Howard, >> >> I just looked, sophia is nothing special. See these microbench results. >>> http

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-04 Thread Howard Chu
Aris Setyawan wrote: Hi Howard, I just looked, sophia is nothing special. See these microbench results. http://pastebin.com/cFK1JsCN LMDB's codebase is still smaller and faster. Nothing else touches LMDB's read speed. This is micro benchmark from sophia author compare with lmdb. http://sphia

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-04 Thread Aris Setyawan
Hi Howard, > I just looked, sophia is nothing special. See these microbench results. > http://pastebin.com/cFK1JsCN > > LMDB's codebase is still smaller and faster. Nothing else touches LMDB's > read > speed. This is micro benchmark from sophia author compare with lmdb. http://sphia.org/benchmark

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-04 Thread Raheel Gupta
>> SQLite4 still in development phase. It is not production ready. But isnt that the same thing as BDB or Kyoto i.e. a Key Value store ? >> If you have many core of processors [and big RAM], then I recommend BDB Sql over Sqlite. I have large space and around 4GB of ram with Dual Cores to Quad Co

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-04 Thread Aris Setyawan
> Will SQLite4 be a better solution for me then ? SQLite4 still in development phase. It is not production ready. > Also @aris do you recommend BDB over Sqlite for 1-10 Billion records ? If you have many core of processors [and big RAM], then I recommend BDB Sql over Sqlite. Because you can have

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-04 Thread Raheel Gupta
Will SQLite4 be a better solution for me then ? Also @aris do you recommend BDB over Sqlite for 1-10 Billion records ? On Mon, Nov 4, 2013 at 8:03 AM, Aris Setyawan wrote: > > I just looked, sophia is nothing special. See these microbench results. > > http://pastebin.com/cFK1JsCN > > > > LMDB'

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-03 Thread Aris Setyawan
> I just looked, sophia is nothing special. See these microbench results. > http://pastebin.com/cFK1JsCN > > LMDB's codebase is still smaller and faster. Nothing else touches LMDB's > read > speed. Focus to the write number. You are using SSD or HDD? On 11/4/13, Howard Chu wrote: > Aris Setyawa

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-03 Thread Howard Chu
Aris Setyawan wrote: SQLightning replaces the SQLite backend with Symas' LMDB, which also uses MVCC and thus supports high concurrency. It is also many times faster than BerkeleyDB and vanilla SQLite. Your MVCC is different compared to InnoDB or BDB locking. Every one should carefully read each

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-03 Thread Howard Chu
Raheel Gupta wrote: @Howard I had tested your code earlier but it didnt seem to be stable and getting it to run was a task. Also I learnt that it is a "in-memory" database. False. LMDB is a memory-mapped disk database, that is not the same as an in-memory database. @Aris are you saying BDB i

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-03 Thread Raheel Gupta
@Howard I had tested your code earlier but it didnt seem to be stable and getting it to run was a task. Also I learnt that it is a "in-memory" database. @Aris are you saying BDB is better and faster than SQLite ? On Sun, Nov 3, 2013 at 8:28 PM, Howard Chu wrote: > Aris Setyawan wrote: > >> SQL

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-03 Thread Howard Chu
Aris Setyawan wrote: SQLightning replaces the SQLite backend with Symas' LMDB, which also uses MVCC and thus supports high concurrency. It is also many times faster than BerkeleyDB and vanilla SQLite. Your MVCC is different compared to InnoDB or BDB locking. Every one should carefully read each

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-03 Thread Aris Setyawan
> SQLightning replaces the SQLite backend with Symas' LMDB, which also uses > MVCC > and thus supports high concurrency. It is also many times faster than > BerkeleyDB and vanilla SQLite. Your MVCC is different compared to InnoDB or BDB locking. Every one should carefully read each DB's doc, then

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-03 Thread Howard Chu
Aris Setyawan wrote: SQLite do not use row level locking, but db level locking, so it was the right behavior the second thread was blocked. For innodb like in SQLite, Oracle have SQLite compatible API, but use BDB backend. Since BDB use MVCC (row/page level locking), your threads only blocked if

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-03 Thread Aris Setyawan
SQLite do not use row level locking, but db level locking, so it was the right behavior the second thread was blocked. For innodb like in SQLite, Oracle have SQLite compatible API, but use BDB backend. Since BDB use MVCC (row/page level locking), your threads only blocked if they will write in the

Re: [sqlite] Row Level Locking as in InnoDB

2013-11-03 Thread Simon Slavin
On 3 Nov 2013, at 1:24pm, Raheel Gupta wrote: > In order to avoid this, I had to use journal_mode=wal so that two threads > dont have to wait when they both are doing SELECTs which might be taking > 3-5 seconds to process. I assume you have designed your indexes specifically for your WHERE and

[sqlite] Row Level Locking as in InnoDB

2013-11-03 Thread Raheel Gupta
Hi, I have been using SQLite for one project of mine and I will be storing TBs of Data. Now there will be a lot of selections in this database and I have come across one problem with SQLite. In journal_mode=delete the selection is database locked. When one thread does a "TRANSACTION" on the databa