You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the mapping table is just a huge fix sized array built into BwTree object (which makes a super heavy object). If NodeID overflows then the entire data structure must be rebuilt with a larger mapping table
This design is not acceptable if the key number grows indefinitely without an upper bound. One alternative would be to use a stack of fixed sized arrays as the mapping table. NodeIDs are dispatched to arrays based on their higher bits, and locates their own slots based on lower bits. When NodeID overflows, the thread just allocate a new fixed sized array and push it into the stack to extend the mapping table. This needs to be done also atomically
The text was updated successfully, but these errors were encountered:
Currently the mapping table is just a huge fix sized array built into BwTree object (which makes a super heavy object). If NodeID overflows then the entire data structure must be rebuilt with a larger mapping table
This design is not acceptable if the key number grows indefinitely without an upper bound. One alternative would be to use a stack of fixed sized arrays as the mapping table. NodeIDs are dispatched to arrays based on their higher bits, and locates their own slots based on lower bits. When NodeID overflows, the thread just allocate a new fixed sized array and push it into the stack to extend the mapping table. This needs to be done also atomically
The text was updated successfully, but these errors were encountered: