You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _parts/part8.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ We're changing the format of our table from an unsorted array of rows to a B-Tre
7
7
8
8
## Alternative Table Formats
9
9
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.
11
11
12
12
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.
13
13
@@ -167,7 +167,7 @@ Every node is going to take up exactly one page, even if it's not full. That mea
167
167
printf("Error closing db file.\n");
168
168
```
169
169
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.
171
171
172
172
```diff
173
173
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
318
318
- table->num_rows = num_rows;
319
319
+
320
320
+ 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.
322
322
+ void* root_node = get_page(pager, 0);
323
323
+ initialize_leaf_node(root_node);
324
324
+ }
@@ -703,7 +703,7 @@ Next time, we'll implement finding a record by primary key, and start storing ro
703
703
- table->num_rows = num_rows;
704
704
+
705
705
+ 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.
0 commit comments