diff options
| author | Mike Hearn <hearn@google.com> | 2012-06-25 11:17:22 +0200 |
|---|---|---|
| committer | Pieter Wuille <pieter.wuille@gmail.com> | 2012-10-20 23:08:56 +0200 |
| commit | 5e650d6d2dbfc284c300668e71188e663d8f0a45 (patch) | |
| tree | bef5ac4e7bfa9845b23ea975be58fa3fe108ef4b /src/leveldb/TODO | |
| parent | 38ac953b9df1f7a884c1ef0e94301e14c4e7477d (diff) | |
| download | bitcoin-5e650d6d2dbfc284c300668e71188e663d8f0a45.tar.xz | |
Import LevelDB 1.5, it will be used for the transaction database.
Diffstat (limited to 'src/leveldb/TODO')
| -rw-r--r-- | src/leveldb/TODO | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/src/leveldb/TODO b/src/leveldb/TODO new file mode 100644 index 0000000000..9130b6a9fa --- /dev/null +++ b/src/leveldb/TODO @@ -0,0 +1,13 @@ +ss +- Stats + +db +- Maybe implement DB::BulkDeleteForRange(start_key, end_key) + that would blow away files whose ranges are entirely contained + within [start_key..end_key]? For Chrome, deletion of obsolete + object stores, etc. can be done in the background anyway, so + probably not that important. + +After a range is completely deleted, what gets rid of the +corresponding files if we do no future changes to that range. Make +the conditions for triggering compactions fire in more situations? |