Monday, April 5, 2004, 3:59:50 PM, Christian Smith wrote:

> You don't have a cache of the Shadows papers, by any chance? The URLs
> referenced appear outdated.

http://citeseer.ist.psu.edu/131901.html

I also have a copy of Tatu Yolen's thesis, but I don't (yet) have his
permission to distribute it. Perhaps his web page will come back on
line soon. http://www.cs.hut.fi/~ylo

e

> Cheers,
> Christian


> On Mon, 5 Apr 2004, Doug Currie wrote:

>>Monday, April 5, 2004, 6:13:18 AM, Christian Smith wrote:
>>
>>> On Wed, 31 Mar 2004, Joel Lucsy wrote:
>>
>>>>Just for the record, for Windows machines, only NTFS v5 formatted
>>>>drives/partitions support sparse files. Windows 2000 or better are the
>>>>only ones supporting NTFS v5. This means Win9x and FAT32 drives under
>>>>2000/XP won't be able to use sparse files.
>>
>>> There are bigger problems anyway.
>>
>>> A snapshot of all old data would be required to be maintained for all
>>> active readers, even if a write transaction has finished. [...]
>>> SQLite would need to maintain a snapshot for each reader, with nothing
>>> but the filesystem to use for IPC. A difficult problem.
>>
>>This is *precisely* the problem my Shadow Pager solves.
>>http://www.sqlite.org/cvstrac/wiki?p=BlueSky
>>
>>> A snapshot might be feasible to maintain from within the same
>>> process, but that would limit concurrent readers and writer to the
>>> same process. [...]
>>
>>Indeed my Shadow Pager design is limited to one process, but I believe
>>that it can be extended to multiple processes by maintaining a list of
>>active transactions, each with a list or bitmap of freed pages, in a
>>lockable shared file.
>>
>>> This gives us the benefit of the better performance the undo based journal
>>> gives us, rather than the redo based journal would give us (redo requires
>>> at least 1 read and 2 writes per page, undo requires 1 read and 1 write
>>> per page in commit.)
>>
>>Shadow Pager requires 1 write per commit, regardless of the number of
>>pages written. There are of course other overheads during the
>>transaction, comparable to the above in cost.
>>
>>e
>>
>>>>Christian Smith wrote:
>>>>
>>>>>How about taking advantage of sparse files (most OS support sparse files)
>>>>>for the journal, and saving the redo pages in the new shadow file. Thus
>>>>>the burden of efficiently handling mapping is bumped down to the OS.
>>>>>
>>>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to