The condition to trigger a split or merge in the current design is
mainly associated with allocation or deallocation of overflow pages. I
tested the performance and found out that 40% of the pages are
overflow pages. This means on average, a record access needs 1.2 disk
I/O. The result is the same as that in [3]. However, we could
also try to use the overall capacity of the index as the trigger
condition. I wish I had time to implement this.
The current design of the 
class is very
elegant in the sense that it eliminates C++ derived-class
hierarchy and it's used very conveniently by access methods, e.g. any
object (bucket page, etc) can be casted to a 
.
But when I was adding code to write update logs, it's really a pain
to find out the PageId of each ``page'' since it's not associated with
its object.
There is a method lock_manager_def::unlockall() which can
unlock all pages locked by a process. It can be used in deadlock
situation to release all the locks a process is holding. Hence at
access method level, if a deadlock is detected, it's not necessary to
release all the locks it has required. I think it's better if we also
have a similar method (of BufMgr) to unpin all the pages a process
pinned.
One last point, since the whole projet cannot be divided into parallel
developments, we should have started the project earlier, especially
for lower level groups, to make sure the whole project can work at the
end of the semester.