|
47 | 47 | * ReorderBuffer uses two special memory context types - SlabContext for |
48 | 48 | * allocations of fixed-length structures (changes and transactions), and |
49 | 49 | * GenerationContext for the variable-length transaction data (allocated |
50 | | - * and freed in groups with similarlifespan). |
| 50 | + * and freed in groups with similarlifespans). |
51 | 51 | * |
52 | 52 | * To limit the amount of memory used by decoded changes, we track memory |
53 | 53 | * used at the reorder buffer level (i.e. total amount of memory), and for |
|
58 | 58 | * Only decoded changes are evicted from memory (spilled to disk), not the |
59 | 59 | * transaction records. The number of toplevel transactions is limited, |
60 | 60 | * but a transaction with many subtransactions may still consume significant |
61 | | - * amounts of memory. The transaction records are fairly small, though, and |
| 61 | + * amounts of memory. The transaction records are fairly small though and |
62 | 62 | * are not included in the memory limit. |
63 | 63 | * |
64 | 64 | * The current eviction algorithm is very simple - the transaction is |
|
69 | 69 | * |
70 | 70 | * We still rely on max_changes_in_memory when loading serialized changes |
71 | 71 | * back into memory. At that point we can't use the memory limit directly |
72 | | - * as we load the subxacts independently. One optiondo deal with this |
| 72 | + * as we load the subxacts independently. One optionto deal with this |
73 | 73 | * would be to count the subxacts, and allow each to allocate 1/N of the |
74 | 74 | * memory limit. That however does not seem very appealing, because with |
75 | | - * many subtransactions it may easily causetrashing (short cycles of |
| 75 | + * many subtransactions it may easily causethrashing (short cycles of |
76 | 76 | * deserializing and applying very few changes). We probably should give |
77 | 77 | * a bit more memory to the oldest subtransactions, because it's likely |
78 | | - * the source for the next sequence of changes. |
| 78 | + *they arethe source for the next sequence of changes. |
79 | 79 | * |
80 | 80 | * ------------------------------------------------------------------------- |
81 | 81 | */ |
|
