Hi,
>> I would also use a b-tree structure. If a node has too many child
>> nodes, two new "invisible internal nodes" are created, and the list of
>> child nodes is split up. Those internal nodes wouldn't have any
>> properties.
>
> You mean a b-tree for each node? I think this could be a separate
> index, but one for the whole tree.
The repository is one large b-tree, and each JCR node is a b-tree node
(except for the JCR nodes that don't have any child nodes: those are
b-tree leaves). If a JCR node has many child nodes, then there is at
least one more level of b-tree nodes between the node and the child
nodes.
> I think supporting fast path lookups for orderable child nodes is a
> bit more important than flat hierarchies
Path lookups would still be fast (the same speed as now), except for
large child node lists that were re-ordered. The difference is only
for large child node lists. There is a difference between 'orderable'
nodes (have the ability to reorder the child node list) and actually
're-ordered' child node lists. Is it acceptable if new nodes appear in
lexicographic order in the child node list?
Regards,
Thomas