Details.

graphs/graphs.ms

@@ -647,14 +647,15 @@ When the value and the index are kept in memory (see \f[CW]RAM only\f[] and \f[C
 In case the value is on the disk, deserialization takes about 15 µs (see \f[CW]Uncached db, cached index\f[]).
 The request is a little longer when the index isn't cached (see \f[CW]Uncached db and index\f[]); in this case DODB walks the file-system to find the right symlink to follow, thus slowing the process even more, by up to 20%.
 
+.ps -2
 .TS
 allbox tab(:);
-c | lw(4.0i) | cew(1.4i).
+c | lw(3.6i) | cew(1.4i).
 DODB instance:Comment and database usage:T{
-compared to RAM only
+compared to RAM-only
 T}
 RAM only:T{
-Worst memory footprint (all data must be in memory), best performance.
+Worst memory footprint, best performance.
 T}:-
 Cached db and index:T{
 Performance for retrieving a value is the same as RAM only while
@@ -665,6 +666,7 @@ Uncached db and index:T{
 Best memory footprint, worst performance.
 T}:400 to 500x slower
 .TE
+.ps \n[PS]
 
 .B Conclusion :
 as expected, retrieving a single value is fast and the size of the database doesn't matter much.
@@ -687,6 +689,8 @@ This section presents all the features I want to see in a future version of the
 Right now, both cached database and cached indexes will store any cached value indefinitively.
 Giving the cache the ability to select the values to keep in memory would enable a massive speed-up even in memory-constrained environments.
 The policy could be as simple as keeping in memory only the most recently requested values.
+
+These new versions of cached database and indexes will become the standard, default DODB behavior.
 .SS Pagination via the indexes: offset and limit
 Right now, browsing the entire database by requesting a limited list at a time is possible, thanks to some functions accepting an
 .I offset