Skip to content

Commit 371aa5a

Browse files
authored
Merge pull request #8 from mattmolo/patch-1
Fixed a few spelling mistakes in part 8
2 parents cfa5078 + 3ea4cae commit 371aa5a

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

_parts/part8.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ We're changing the format of our table from an unsorted array of rows to a B-Tre
77

88
## Alternative Table Formats
99

10-
With the current format, each page stores only rows (no metadata) so it is pretty space efficient. Insertion is also fast because we just append to the end. However, finding a particular row can only be done by scanning the entire table. And if we want to delete a row, we have to to fill in the hole by movinvg every row that comes after it.
10+
With the current format, each page stores only rows (no metadata) so it is pretty space efficient. Insertion is also fast because we just append to the end. However, finding a particular row can only be done by scanning the entire table. And if we want to delete a row, we have to fill in the hole by moving every row that comes after it.
1111

1212
If we stored the table as an array, but kept rows sorted by id, we could use binary search to find a particular id. However, insertion would have the same problem as deletion where we have to move a lot of rows to make space.
1313

@@ -167,7 +167,7 @@ Every node is going to take up exactly one page, even if it's not full. That mea
167167
printf("Error closing db file.\n");
168168
```
169169

170-
Now it makes more sense to store the number of pages in our database rather than the number of rows. The number of pages should be assoicated with the pager object, not the table, since it's the number of pages used by the database, not a particular table. A btree is identified by its root node page number, so the table object needs to keep track of that.
170+
Now it makes more sense to store the number of pages in our database rather than the number of rows. The number of pages should be associated with the pager object, not the table, since it's the number of pages used by the database, not a particular table. A btree is identified by its root node page number, so the table object needs to keep track of that.
171171

172172
```diff
173173
const uint32_t PAGE_SIZE = 4096;
@@ -318,7 +318,7 @@ When we open the database for the first time, the database file will be empty, s
318318
- table->num_rows = num_rows;
319319
+
320320
+ if (pager->num_pages == 0) {
321-
+ // New database file. Initialze page 0 as leaf node.
321+
+ // New database file. Initialize page 0 as leaf node.
322322
+ void* root_node = get_page(pager, 0);
323323
+ initialize_leaf_node(root_node);
324324
+ }
@@ -703,7 +703,7 @@ Next time, we'll implement finding a record by primary key, and start storing ro
703703
- table->num_rows = num_rows;
704704
+
705705
+ if (pager->num_pages == 0) {
706-
+ // New database file. Initialze page 0 as leaf node.
706+
+ // New database file. Initialize page 0 as leaf node.
707707
+ void* root_node = get_page(pager, 0);
708708
+ initialize_leaf_node(root_node);
709709
+ }

0 commit comments

Comments
 (0)