The file is a strip of pages — 4 KB page reads and OS block alignment
The DB file is a strip of identical fixed-size pages — every read/write is one whole page because the disk and OS work in pages.
We need an ordered structure. Before we can build it, we have to know what the storage substrate looks like — and it's not a sea of bytes.
Scene 02
The file is a strip of pages
- Watch
- Try it
- Predict
- Capture
The file isn't a soup of bytes — it's a strip of identical pages. Watch the read-head sweep across them; each landing is one disk I/O. Then an INSERT picks exactly ONE page as rowid 42's home.
Highlighted lines are the ones running in the diagram right now.
def read_one_row(file, page_size, page_no, row_offset):# disk addresses are page numbers, not byte offsetsoffset = (page_no - 1) * page_sizepage_buf = read(file, offset, page_size) # one I/O = one page# row extraction happens entirely in RAMrow = extract_row_from_page_buffer(page_buf, row_offset)return row
def effective_io(row_size, page_size, os_block=4096):if page_size < os_block:# sub-block page: kernel still drags a whole 4 KB block,# SQLite throws the rest awaysub = os_block // page_sizereturn os_block # waste = (sub - 1) * page_size per readif page_size == os_block:# aligned: one page = one block = one disk transferreturn os_block# supra-block page: one logical read spans many blocksblocks = page_size // os_blockreturn blocks * os_block # bandwidth = blocks * 4 KB per row
Where this sits in Build a B-tree storage engine (SQLite-style)
Scene 02 of 11, in the Anatomy act — Pages, the tree of pages, and how a search descends.. The DB file is a strip of identical fixed-size pages — every read/write is one whole page because the disk and OS work in pages.
Up next. We have a strip of fixed-size pages, but no order yet. The next scene links pages into a tree so we can find any row in a few page reads instead of N.
All 11 scenes in Build a B-tree storage engine (SQLite-style) · Every curriculum