better results for esquelito

1 files changed, 4 insertions, 5 deletions

diff --git a/doc/design/caching_database.mdwn b/doc/design/caching_database.mdwn
index 5c32fa407..7fd5f37eb 100644
--- a/doc/design/caching_database.mdwn
+++ b/doc/design/caching_database.mdwn
@@ -43,7 +43,7 @@ that I could use instead. But, acid-sate needs to load the whole
 DB into memory. In the comments of
 [[bugs/incremental_fsck_should_not_use_sticky_bit]] I examined several
 other haskell database-like things, and found them all wanting, except for
-possibly TCache.
+possibly TCache. (And TCache is backed by persistent/sqlite anyway.)
 
 ## case study: persistent with sqllite
 
@@ -120,15 +120,14 @@ With this, 1000 queries takes 0.406s. Note that persistent is probably not
 actually doing a join at the SQL level, so this could be sped up using
 eg, esquelito.
 
-Update2: Using esquelito to do a join got this down to 0.250s.
-
-Code: <http://lpaste.net/101141> <http://lpaste.net/101142>
+Update2: Using esquelito to do a join got this down to 0.109s.
+See `database` branch for code.
 
 Compare the above with 1000 calls to `associatedFiles`, which is approximately
 as fast as just opening and reading 1000 files, so will take well under
 0.05s with a **cold** cache.
 
-So, we're looking at nearly an order of magnitude slowdown using sqlite and
+So, we're looking at maybe 50% slowdown using sqlite and
 persistent for associated files. OTOH, the normalized schema should
 perform better when adding an associated file to a key that already has many.