Re: [sqlite] Concurrency, MVCC

2004-04-16 Thread Christian Smith
On Thu, 15 Apr 2004, Doug Currie wrote: > >Thursday, April 15, 2004, 9:16:01 AM, Christian Smith wrote: > >> On Wed, 14 Apr 2004, Doug Currie wrote: > >>>One way to get table level locking without a great deal of pain is to >>>integrate the shadow paging ideas with BTree management. Rather than

Re: [sqlite] Concurrency, MVCC

2004-04-15 Thread Mark D. Anderson
On Thu, 15 Apr 2004 20:16:32 -0400, "Doug Currie" <[EMAIL PROTECTED]> said: > I used this design in a proprietary database in the late 1980s. The > only reason I didn't consider modifying SQLite this way up until now > is that I was anticipating BTree changes for 3.0, so I confined my > efforts

Re: [sqlite] Concurrency, MVCC

2004-04-15 Thread Doug Currie
Thursday, April 15, 2004, 9:16:01 AM, Christian Smith wrote: > On Wed, 14 Apr 2004, Doug Currie wrote: >>One way to get table level locking without a great deal of pain is to >>integrate the shadow paging ideas with BTree management. Rather than >>using page tables for the shadow pages, use the

Re: [sqlite] Concurrency, MVCC

2004-04-15 Thread Christian Smith
On Thu, 15 Apr 2004, Andrew Piskorski wrote: >On Thu, Apr 15, 2004 at 02:16:01PM +0100, Christian Smith wrote: >> Right tool for the job. Multiple writers has client/server database >> written all over it. KISS. > >No, not true, at least not when the multiple writers are all threads >within one

Re: [sqlite] Concurrency, MVCC

2004-04-15 Thread Andrew Piskorski
On Thu, Apr 15, 2004 at 02:16:01PM +0100, Christian Smith wrote: > Right tool for the job. Multiple writers has client/server database > written all over it. KISS. No, not true, at least not when the multiple writers are all threads within one single process, which appears to be the common case

Re: [sqlite] Concurrency, MVCC

2004-04-15 Thread Christian Smith
On Wed, 14 Apr 2004, Doug Currie wrote: >Wednesday, April 14, 2004, 1:16:54 AM, Andrew Piskorski wrote: > >> How could this be extended to support table locking and PostgreSQL's >> default "read committed" isolation level? Would the smallest locking >> granularity possible in Currie's design be

Re: [sqlite] Concurrency, MVCC

2004-04-15 Thread Mark D. Anderson
On Wed, 14 Apr 2004 08:13:39 -0400, "D. Richard Hipp" <[EMAIL PROTECTED]> said: >* Support for atomic commits of multi-database transactions, > which gives you a limited kind of table-level locking, > assuming you are willing to put each table in a separate > database. and

Re: [sqlite] Concurrency, MVCC

2004-04-14 Thread Mark D. Anderson
Wednesday, April 14, 2004, 1:16:54 AM, Andrew Piskorski wrote: > as far as I can tell, it seems to be describing a system with > the usual Oracle/PostgreSQL MVCC semantics, EXCEPT of course that > Currie proposes that each Write transaction must take a lock on the > database as a whole. Well, i

Re: [sqlite] Concurrency, MVCC

2004-04-14 Thread Doug Currie
> D. Richard Hipp wrote: >> >> My thoughts on BlueSky have been added to the wiki page: >>http://www.sqlite.org/cvstrac/wiki?p=BlueSky I added some responses; I do not agree with Richard's concerns about Shadow Paging, and I corrected some mistaken conclusions. I apologize if my paper was

Re: [sqlite] Concurrency, MVCC

2004-04-14 Thread D. Richard Hipp
D. Richard Hipp wrote: My thoughts on BlueSky have been added to the wiki page: http://www.sqlite.org/wiki?p=BlueSky That URL should have been: http://www.sqlite.org/cvstrac/wiki?p=BlueSky Left out the "cvstrac". Sorry for the confusion. -- D. Richard Hipp -- [EMAIL PROTECTED] --

Re: [sqlite] Concurrency, MVCC

2004-04-14 Thread D. Richard Hipp
Andrew Piskorski wrote: How feasible would it be to add support for higher concurrency to SQLite, especially via MVCC? My thoughts on BlueSky have been added to the wiki page: http://www.sqlite.org/wiki?p=BlueSky The current plan for version 3.0 is as follows: * Support for a modification

[sqlite] Concurrency, MVCC

2004-04-13 Thread Andrew Piskorski
How feasible would it be to add support for higher concurrency to SQLite, especially via MVCC? (If it turns out to be feasible and desirable, I'd be willing to work on it in my free time.) What I would really like in SQLite would be: - Good concurrency, preferably similar or better to that of