Update copy

Author: cstack

_parts/part13.md

@@ -295,7 +295,7 @@ After a bunch of debugging, I discovered this was due to some bad pointer arithm
  }
 ```
 
-`INTERNAL_NODE_CHILD_SIZE` is 4. My here intention was to add 4 bytes to the result of `internal_node_cell()`, but since `internal_node_cell()` returns a `uint32_t*`, this it was actually adding `4 * sizeof(uint32_t)` bytes. I fixed it by casting to a `void*` before doing the arithmetic.
+`INTERNAL_NODE_CHILD_SIZE` is 4. My intention here was to add 4 bytes to the result of `internal_node_cell()`, but since `internal_node_cell()` returns a `uint32_t*`, this it was actually adding `4 * sizeof(uint32_t)` bytes. I fixed it by casting to a `void*` before doing the arithmetic.
 
 NOTE! [Pointer arithmetic on void pointers is not part of the C standard and may not work with your compiler](https://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c/46238658#46238658). I may do an article in the future on portability, but I'm leaving my void pointer arithmetic for now.
 

_parts/part5.md

@@ -122,7 +122,7 @@ Following our new abstraction, we move the logic for fetching a page into its ow
  }
 ```
 
-The `get_page()` method has the logic for handling a cache miss. We assume pages are saved one after the other in the database file: Page 0 at offset 0, page 1 at offset 4096, page 2 at offset 8192, etc. If the requested page lies outside the bounds of the file, we know it should be blank, so we just allocate some memory return it. The page will be added to the file when we flush the cache to disk later.
+The `get_page()` method has the logic for handling a cache miss. We assume pages are saved one after the other in the database file: Page 0 at offset 0, page 1 at offset 4096, page 2 at offset 8192, etc. If the requested page lies outside the bounds of the file, we know it should be blank, so we just allocate some memory and return it. The page will be added to the file when we flush the cache to disk later.
 
 
 ```diff
@@ -290,7 +290,9 @@ The next 256 bytes store the email in the same way. Here we can see some random
 
 ## Conclusion
 
-Alright! We've got persistence. It's not the greatest. For example if you kill the program without typing `.exit`, you lose your changes. Additionally, we're writing all pages back to disk, even pages that haven't changed since we read them from disk. These are issues we can address later. The next thing I think we should work on is implementing the B-tree.
+Alright! We've got persistence. It's not the greatest. For example if you kill the program without typing `.exit`, you lose your changes. Additionally, we're writing all pages back to disk, even pages that haven't changed since we read them from disk. These are issues we can address later.
+
+Next time we'll introduce cursors, which should make it easier to implement the B-tree.
 
 Until then!
 

_parts/part7.md

@@ -8,7 +8,7 @@ The B-Tree is the data structure SQLite uses to represent both tables and indexe
 Why is a tree a good data structure for a database?
 
 - Searching for a particular value is fast (logarithmic time)
-- Inserting / deleting a value is fast (constant-ish time to rebalance)
+- Inserting / deleting a value you've already found is fast (constant-ish time to rebalance)
 - Traversing a range of values is fast (unlike a hash map)
 
 A B-Tree is different from a binary tree (the "B" probably stands for the inventor's name, but could also stand for "balanced"). Here's an example B-Tree:
@@ -51,6 +51,7 @@ Let's work through an example to see how a B-tree grows as you insert elements i
 - up to 3 children per internal node
 - up to 2 keys per internal node
 - at least 2 children per internal node
+- at least 1 key per internal node
 
 An empty B-tree has a single node: the root node. The root node starts as a leaf node with zero key/value pairs:
 

_parts/part8.md

@@ -9,7 +9,7 @@ We're changing the format of our table from an unsorted array of rows to a B-Tre
 
 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.
 
-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.
+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 be slow because we would have to move a lot of rows to make space.
 
 Instead, we're going with a tree structure. Each node in the tree can contain a variable number of rows, so we have to store some information in each node to keep track of how many rows it contains. Plus there is the storage overhead of all the internal nodes which don't store any rows. In exchange for a larger database file, we get fast insertion, deletion and lookup.