Performance Contest
Students groups are encouraged to enter their solutions for the third and fourth assignments into a performance contest. We will run a given workload and measure the performance of each solution in terms of I/O and CPU time. The three groups with the most efficient solutions will retrieve small prices.
Workloads
We will have three workloads with large numbers of randomly generated requests. For all workloads the buffer size will be fixed, but each group can choose the page replacement strategy sued for the buffer pool. The record manager and b-tree applications have to access pages through the buffer pool and are not allowed to circumvent the pool. You are allowed to allocate small, fixed amounts of additional memory for, e.g., evaluating scan conditions. We will provide code to execute one specific instance of each workload. This code will be uploaded to the contest directory in your repository.
- Workload Set 1: This set of workloads creates a table upfront and then performs only read operations. Time and I/O measurements start after the table has been created. The workload switches between two types of scans: random scans that match a single tuple and random scans that match 100 tuples.
- Workload Set 2: The workloads in this set balances updates, inserts, deletes, and read.
Restrictions
For your implementation to be accepted for the contest you have to follow these rules.
- Your code has to compile on fourier, the machine you got an account for in the beginning!
- The record manager and b-tree applications have to access pages through the buffer pool and are not allowed to circumvent the pool.
- You are not allowed to allocate additional memory to cache pages to circumvent the page size restrictions. Small amounts of memory for evaluating expressions and similar are ok.
- You are allowed to open several buffer pools, but the total number of pages allocated by these pool has to be the size specified for the contest. For example, if your record manager uses a b-tree that is stored in another page file, then you could open one buffer pool for the b-tree and another one for main data file.
Measurements
For each workload we will measure the total execution time (averaged over several runs), the total number of page reads, and total number of page writes.
Instructions
We will upload the contest code to a folder contest in your git repository. Please add your *.c, *.h, etc. from assignment3/4 to this folder and make sure it compiles. We add a Makefile and header contest.h. Feel free to modify the Makefile if your code needs a custom makefile. Please implement the two functions RC setUpContest (int numPages) and RC shutdownContest() from contest.h. The first function should start up your record manager, index manager, and storage manager and create buffer pool(s) with at most numPages pages in total. Please modify the existing implementations of these functions in contest_setup.c. For example, if numPages = 100 and your record manager uses a b-tree with its own buffer pool, then you could allocate 30 pages to the b-tree buffer pool and 70 for buffering pages of the table. shutdown should free up available resource and shutdown all components. Make sure that you makefile creates an executable contest from the file contest.c.
Furthermore, you need to implement a function long getContestNumIO () to that returns the number of IO operations since setUpContest was called.