BufferPool Caching & Durability

[buttke]

Relevant structs:

/// Contains one record field. Because all fields are 64 bit integers, we use `i64`.
/// If a field has been written, it contains `Some(i64)`. Otherwise, it holds `None`.
#[derive(Copy, Clone, Debug)]
struct Cell(Option<i64>);

/// Represents a physical page. In our design, every physical page has 512 cells. Therefore,
/// each has a size of **4096 bytes**.
#[derive(Clone, Copy, Debug)]
pub struct Page {
    /// Fixed size array of cells.
    cells: [Cell; CELLS_PER_PAGE],

    /// The number of cells currently written. Also represents the next available index.
    cell_count: usize,
}

/// Represents the buffer pool manager. For now it only interacts with the memory, but in future
/// milestones, it'll interact with the disk as well. One instance of the buffer pool manager is
/// shared by _all_ tables using `Arc<Mutex<>>`.
#[derive(Clone)]
#[pyclass]
pub struct BufferPool {
    /// Contains physical pages for all tables. 
    pages: Vec<Page>
}

Need:

• per Frame page:

  • atomic Pin counter (per Frame) ARC handles pins (# refs)
  • write lock (per Frame)
  • dirty "bit" (per Frame)

• BufferPool impl:

  • BufferPool write_page_to_file(); method
  • BufferPool load_page(); method

Logic changes:

• Hook up reading/writing methods with caching logic.

Further notes:

We will use flate2's zlib compression https://github.com/rust-lang/flate2-rs

We will need additional table metadata present in the bufferpool in order to organize the page files in the filesystem (i.e. on disk)

[buttke]

bufferpool may need to become something like array [Box<Frame>, NUM_BUFPOOL_MEM_PAGES]

[buttke]

Pin Count is not needed if each frame has an Arc<RwLock>. Because the Arc counts references