agora inbox for postgres@postgres.berkeley.edu  
help / color / mirror / Atom feed
From: Paul M. Aoki <aoki@postgres.Berkeley.EDU>
To: Michael Ubell <michael@montage.com>
Cc: Mark Metson <gpurdy@fox.nstn.ns.ca>
Cc: postgres@postgres.Berkeley.EDU
Subject: locking [was: Use by a Business]
Date: Mon, 30 May 94 19:53:06 -0700
Message-ID: <199405310253.TAA20627@faerie.CS.Berkeley.EDU> (raw)
In-Reply-To: <9405301947.AA02892@pigpen.montage.com>

Michael Ubell <michael@montage.com> writes:
> >  it does do page-level locking for b-trees but not for r-trees and heaps.
> Doing page locking on b-trees but not on the underlying heap does not really
> buy you anything since if you do an update the whole heap table is locked so
> things will be single threaded no matter what you do in the b-tree.

well, yes.  to quote src/doc/implementation/am.me, written by mike 
olson (now at montage):

          Users  of the access method interface routines need not
     worry about locking.  The  access  method  routines  acquire
     (and,  when  appropriate,  release)  locks  on  relations in
     response to scans and updates.  Heap relations are protected
     by  two-phase  relation  level  locks.   Btree  indices  use
     Lehman-Yao5 short-term locking  for  high  concurrency,  but
     since  the  underlying  relations are locked at the relation
     level, index updates are serialized.  Rtree indices use two-
     phase relation-level locking.

        5 Lehman, P., Yao, S., ``Efficient Locking for Concurrent
     Operations  on  B-trees'', ACM Transactions on Database Sys-
     tems, 6(4), December 1981.

but having working b-link trees reduces the amount of work some 
hypothetical person would have to do to convert the core system to 
page-level locking.

(not that the last two messages have had anything to do with what 
the guy was asking..)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"

   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================



reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: postgres@postgres.berkeley.edu
  Cc: aoki@postgres.Berkeley.EDU, michael@montage.com, gpurdy@fox.nstn.ns.ca
  Subject: Re: locking [was: Use by a Business]
  In-Reply-To: <199405310253.TAA20627@faerie.CS.Berkeley.EDU>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox