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
using page
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 also a
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 one page of
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 for
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 BTrees
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 to the
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
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] --
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 not clear
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
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
11 matches
Mail list logo
