[
https://issues.apache.org/jira/browse/CASSANDRA-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591256#comment-16591256
]
Benedict commented on CASSANDRA-9989:
-------------------------------------
bq. We can make it more clear with: {{(size / (childSize + 1)) + 1}}
Ha. Doh.
bq. It's also used here
I guess we should decide on our split strategy then, as this code is new, and
you added it AFAICT because of miscommunication on my part. My view is that
either your prior code (that is *conceptually* consistent with the old
approach), or an even split between all of the child nodes, is preferable. I
think the latter is actually superior, as it provides more opportunities on
update to copy an unadulterated sub-tree (with full nodes we have to split,
spilling up to the root).
Either way, if we remove the legacy replication, this grandchild calculation
goes away, and we can clarify TREE_SIZE?
> 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
