summaryrefslogtreecommitdiff
path: root/doc/devblog
diff options
context:
space:
mode:
authorGravatar Richard Hartmann <richih@debian.org>2014-03-15 08:16:46 +0100
committerGravatar Richard Hartmann <richih@debian.org>2014-03-15 08:16:46 +0100
commit52a87885ed9568fd3b350cca9a0c7aacb0955ec0 (patch)
tree98ac7e68bb28175b0b3478876a8e64fc657a8b05 /doc/devblog
parent8f8ce35ec8f26999e01f70d6852b527c0410da4e (diff)
Wording and link
Diffstat (limited to 'doc/devblog')
-rw-r--r--doc/devblog/day_132__database_musings.mdwn7
1 files changed, 4 insertions, 3 deletions
diff --git a/doc/devblog/day_132__database_musings.mdwn b/doc/devblog/day_132__database_musings.mdwn
index 559ad8685..76ce14c32 100644
--- a/doc/devblog/day_132__database_musings.mdwn
+++ b/doc/devblog/day_132__database_musings.mdwn
@@ -3,14 +3,15 @@ the last release unexpectedly fixed XMPP SIGILL on some OSX machines.
Apparently when I rebuilt all the libraries recently, it somehow fixed that
[[old_unsolved_bug|bugs/Share_with_friends_crash_in_osx]].
-RichiH suggested "wrt balloning memory on repair: can you read in broken
+[RichiH](http://richardhartmann.de/) suggested "wrt ballooning memory on
+repair: can you read in broken
stuff and simply stop reading once you reach a certain threshold, then
start repairing, re-run fsck, etc?" .. I had considered that but was
not sure it would work. I think I've gotten it to work.
Now working on a design for using a [[design/caching_database]]
-for some parts of git-annex. My initial benchmarks using sqlite
+for some parts of git-annex. My initial benchmarks using SQLite
indicate it would slow down associated file lookups by nearly an order of
magnitude compared with the current ".map files" implementation.
-(But would scale better in edge cases). OTOH, using a sqlite
+(But would scale better in edge cases). OTOH, using a SQLite
database to index metadata for use in views looks very promising.