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
>>
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 t
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
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 si
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 fo
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 on
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 als
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 su
Wednesday, April 14, 2004, 1:16:54 AM, Andrew Piskorski wrote:
>[...]
> Doug Currie's "Shadow Paging" design sounds promising.
> Unfortunately, I have not been able to download the referenced
> papers at all (where can I get them?),
There are three sources for the papers. The two links on the wi
> 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
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] -- 704.948
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
12 matches
Mail list logo
