/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/implementation-notes.txt

  • Committer: John Arbash Meinel
  • Date: 2009-10-29 16:15:43 UTC
  • mto: This revision was merged to the branch mainline in revision 4780.
  • Revision ID: john@arbash-meinel.com-20091029161543-tdqlm2l4e2z5o7le
We don't have to pad 'short' records.

When writing a row, we reserve 120 bytes from the first node so that we
can write our 'B+Tree Graph Index' signature and other meta-information.
For the root node, we don't always use the 120 bytes, and for non-root
rows, we don't use that data at all. So we usually pad back that
record. However, for indexes that fit entirely in the root record,
we don't pad them to 4096, and it turns out we don't need to pad
them with the spare 120 bytes either.

I was doing a test with lots of 'chained' btree indexes, and this
extra padding ended up being 4.6M => 4.3M of wasted space. I imagine
that bzr-search will have a similar issue with tiny indexes.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
Implementation notes
 
2
====================
 
3
 
 
4
.. toctree::
 
5
   :hidden:
 
6
 
 
7
   btree_index_prefetch
 
8
   last-modified
 
9
   content-filtering
 
10
   lca_tree_merging
 
11
 
 
12
 
 
13
* `BTree Index Prefetch <btree_index_prefetch.html>`_ |--| How bzr decides
 
14
  to pre-read extra nodes in the btree index.
 
15
 
 
16
* `Computing last_modified values <last-modified.html>`_ for inventory
 
17
  entries
 
18
 
 
19
* `Content filtering <content-filtering.html>`_
 
20
 
 
21
* `LCA Tree Merging <lca_tree_merging.html>`_ |--| Merging tree-shape when
 
22
  there is not a single unique ancestor (criss-cross merge).
 
23
 
 
24
 
 
25
.. |--| unicode:: U+2014
 
26
 
 
27
..
 
28
   vim: ft=rst tw=74 ai