[
https://issues.apache.org/jira/browse/CASSANDRA-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16594817#comment-16594817
]
Benedict commented on CASSANDRA-9989:
-------------------------------------
Thanks Jay, looks good. A couple more follow-up comments:
# It might be nice to rename {{pos}} to {{index}} for consistency with
{{indexOffsets}}
# It might be nicer to split even more evenly, as far as possible - if only
from a code perspective. The situation you're accounting for of a single key
in the final child could be resolved by decrementing some K from every other
node, I think.
This second is only a suggestion, as I haven't tried to implement it, but I
feel it would be a little more consistent to have {{[N-k,N-k,…,N-k,remainder]}}
than to have {{[N,N...,N,remainder/2, remainder/2]}}. It would also mean a
single clearly explained bit of upfront logic to decide if we need to adjust,
and the loop can apply to all nodes but the last.
As a simple ‘proof’, there will be max {{BF+1}} children, so a max of {{BF}}
neighbours. So deducting 1 from all of them, in the event that the right-hand
node is going to have a solitary key, will increase its size by at most 1 leaf
node. This is guaranteed to fit unless the node was already a leaf, in which
case we didn’t need to do anything anyway. The only scenario I can imagine
being a problem would be a deep tree, for which we probably want to calculate
{{MIN_TREE_SIZE}}, as we might need to deduct more than 1.
WDYT?
bq. LongBTreeTest.java is timing out even for trunk, I'm increasing timeout and
run through the test.
You can run this with its {{main()}} method
> Optimise BTree.Buider
> ---------------------
>
> Key: CASSANDRA-9989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9989
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Benedict
> Assignee: Jay Zhuang
> Priority: Minor
> Fix For: 4.x
>
> Attachments: 9989-trunk.txt
>
>
> BTree.Builder could reduce its copying, and exploit toArray more efficiently,
> with some work. It's not very important right now because we don't make as
> much use of its bulk-add methods as we otherwise might, however over time
> this work will become more useful.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
