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 rows, however
>> many rows that happens to be?
>
>Things get *much* more complicated once you have multiple simultaneous
>write transactions. I didn't want to go there.
Right tool for the job. Multiple writers has client/server database
written all over it. KISS.
>
>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 themselves.
>This means that any change to a BTree requires changes along the
>entire path back to the root so that only free pages are used to store
>new data, including the BTree itself. Writing the root page(s) of the
>BTree(s) commits the changes to that table (these tables).
Actually, this gets my vote. Keeps the pager layer the same, and only
requires a cache of the root btree for each object (table/index) in the
database to be maintained on a per-transaction basis, reducing the
complications of what to do under memory pressure when pages are spilled
from the cache as we should be able to keep them in memory all the time.
Committing of a transaction would then be an atomic update root btree page
number in the catalog table.
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
