Chenxiao Ma
504079332
[email protected]

Peipei Zhou
204176631
[email protected]

Part A:
is trivial.

Part B:
Chenxiao coded BTLeafNode class.
Peipei coded BTNonLeafNode class.

Each BTLeafNode can hold (1024-4)/12 = 85 (RecordId, key) pairs at most.
Each BTNonLeafNode can hold (1024-4)/8 = 172 (key, PageId) pairs at most.

For convenience, we decided to implement the Maximum number N of keys stored in a node to be 60 for BTLeafNode and 100 for BTNonLeafNode. 

Part C:
We used 1(one) grace day.

Chenxiao coded BTreeIndex::open(), BTreeIndex::close(), BTreeIndex::insert()
Peipei coded BTreeIndex::locate(), BTreeIndex::readForward(), BTreeIndex::recInsert()

we slightly modified BTreeNode.cc and believed the change is less than 50%

Part D:
We used 1(one) grace day.
We coded together.

We modified BTreeIndex class and now it can return the max and min key in the index.
We used max and min key to decide wether a key-specified condition is out of range or not.

Testing Info:
-- 1 page read only because when select COUNT(*) AND key-specified condition 
-- is out of data range, it will read from the first page of xlarge.indx and give
-- the result directly
SELECT COUNT(*) FROM xlarge;
SELECT COUNT(*) FROM xlarge where key<2147483647

-- 29 pages read because it didn't read xlarge.tbl
SELECT COUNT(*) FROM xlarge WHERE key<2500 AND key>1000;
SELECT key FROM xlarge WHERE key<2500 AND key>1000;

-- 1061 pages read because whenever it has a value-specifed condition or
-- select value statement it will use xlarge.idx and also read xlarge.tbl
SELECT * FROM xlarge WHERE key<2500 AND key>1000;
SELECT value FROM xlarge WHERE key<2500 AND key>1000;
SELECT key FROM xlarge WHERE value <= 'Z' AND key<2500 AND key>1000;

-- These three queries are equivalent. The first query will use a linear scan while the second
-- one will do a index-based scan. However, in this case linear scan will be much faster than 
-- index-based scan. The third query is the simplified version from the first and second query
SELECT * FROM xlarge WHERE key>0 AND key < 2016123412;
SELECT * FROM xlarge WHERE key>0 AND key < 2016123410;
SELECT * FROM xlarge WHERE key>0

-- A bug was fixed with this query
SELECT count(*) FROM xlarge WHERE key>100 AND key<>40

-- These two cases have been optimized. When key-specified conditions are out of range, we don't
-- need to scan either index or record file
SELECT * FROM xlarge WHERE key > 2016123412;
SELECT * FROM xlarge WHERE key < 2;