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]