If the values in the index nodes are actual keys and not some analyzed version of them (which is what I was incorrectly calling the hashed key) then it seems there would be a way to construct the keys in the db by only visiting the index nodes.
Berkeley's BTree DBs are actually B+Trees, where all the values (*), are kept in the leaf nodes along with their respective keys. In-order traversal is done by locating the leaf block for the 'lowest' key, and then following peer-level pointers to move from leaf to leaf. Therefore, traversing the entire key-space will mean reading all the keys & values from disk.
(*)Unless the data values are too large to store in the chosen page-size, in which case 'overflow records' are used.
The concern is maintaining coherency and that's why I was hoping to avoid it.
If you use the tied hash interface, you could override the STORE() and DELETE() methods to maintain the key list entry. You could also use the fact that BDB allows you to maintain more than one DB in a single file to store that list as the only record in a second DB. That ought to ensure that single record is perpetually cached.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |