Talk:B+ tree

message: inner insert breay, this diagram erringly splits nodes right when they reach capacity, thus precluding there ever being any "full" nodes.  B-tree algorithms (and B+-tree) are supposed to split nodes only after capacity is reached and a new value is tried to be inserted in a full node. 132.198.12.98 21:30, 30 November 2007 (UTC)
replies: text: The diagram is incorrect and has been removed. While there are some implementations of B+ trees that do split before the block is full (this allows you to perform the split after insertion is completed), this is not the "normal" procedure.78.91.39.182 15:13, 1 December 2007 (UTC)

message: The diagram isn't very clear. It doesn't show that the data matches the keys, and it makes the 'linked list' pointers much different than the data pointers.  —Preceding unsigned comment added by 24.26.131.178 (talk) 04:46, 4 December 2007 (UTC)
thread_title:  Diagram 

message: It seems to me like the main difference between B-Trees and B+-Trees is a relatively minor one that has little effect on how operations proceed, which renders much of this article redundant with B-tree. I suggest this article be merged into B-tree and become a section of that article. Dcoetzee 03:58, 2 December 2008 (UTC)
replies: text: Can't support this. The differences might not be obvious but lie in details. B+ trees have much more problems which are not discussed in the B-Tree article. For example how do you handle duplicate keys during deletion? Duplicate keys do not exist for regular B-Trees, therefore it's not an issue there. The differences affect all the algorithms, therefore it would not make sense to merge both articles.  — Preceding unsigned comment added by 2001:41B8:83C:FA01:49DA:DF76:DF61:15D3 (talk) 12:12, 13 November 2018 (UTC)
thread_title:  Merge suggested 

message: Am I not correct that the current diagram doesn't show a B+ Tree at all? First, nodes will have between N and 2N entries. Which integer N is 3 twice?
:You are not correct.  B+ trees are order B trees (a node must have between 1 and B children), and B doesn't have to be 2, it can take any integer value greater than 1.Michealt (talk) 11:47, 29 August 2011 (UTC)
thread_title:  Diagram 

message: Ramakrishnan's book on DBMS says that tree order of d means size of each internal node can range between d <= m <= 2d. However this article says it ranges between d/2 <= m <= d. I am not sure which one is correct. But majority of the CS Schools around take Ramakrishnan's book as reference. So this may be written wrong in the article.   — Preceding unsigned comment added by 95.15.75.81 (talk) 18:18, 17 December 2011 (UTC)
replies: text:  This depends on whether you define "tree order d" as minimum tree order or maximum tree order. Both are valid. 2001:41B8:83C:FA01:49DA:DF76:DF61:15D3 (talk) 12:14, 13 November 2018 (UTC)
replies: text:  Fair enough, but that is not consistent with the definition given in the related article about B-trees, which uses the formula of the original paper (Bayer et al., 1972https://link.springer.com/article/10.1007%2FBF00288683), although that one never explicitly talks about "order" in the sense of minimum or maximum number of index entries on a page. I would propose to go with the textbook definition of "order" (d <= m <= 2d) here which also is consistent with the B-tree article on here. 134.34.231.91 (talk) 09:24, 11 July 2019 (UTC)
thread_title:  Tree Order 

message: The only sentence that separates this from the B-tree article is In a B+ tree, in contrast to a B-tree, all records are stored at the leaf  level of the tree; only keys are stored in interior nodes.  
Can someone add why you'd use a B+ tree instead of a B tree?  There seem to be a lot of database solutions using B+ trees, so there has to be a reason, but without that reason, this article doesn't differ substantially from the B tree article.  Dean (talk) 14:14, 22 July 2010 (UTC)
replies: text: I've added some content to the implementation section describing at least one advantage of a B+-tree over a B-tree in the context of database systems. It seems to me that merging these two articles wouldn't be a great idea; while it's true that the articles are similar, that's largely due to a lack of detail on the insert and delete algorithms. There are subtle differences in how these work. If someone were to put in detailed pseudocode for these algorithms, they'd be somewhat different. That would make for quite a large merged article. While it's true that merging them now without that content might make some sense, it just means that someday, when someone wants to put in the detailed pseudocode, someone else would suggest splitting them. Maybe someone should just put in detailed code now? SeparateWays (talk) 19:02, 22 July 2010 (UTC)
thread_title:  Merge or Additional Clarity 

message: as seperator keys are copied from leaf and can be subsequently moved to higher index nodes, while deleting a key value we have to delete the key twice, once from the leaf and once from the index, right? 
                      9
                   /     \
            2 5 - -       11    17        21     -
           / | \         /      |         |  \
               5 6 7 - 9 10 - - 11 12 13 -
like in this case if we want to delete 9, we first delete 9 from leaf; which will be prevented from underflowing by borrowing 11 from right sibling, adjusting their seperator entry in parent to 12 subsequently. The tree will then look like
                      9
                   /     \
            2 5 - -       12     17       21     -
           / | \         /       |        |  \
               5 6 7 - 10 11 - - 12 13 - -
but should we then delete the entry 9 from the root? which will need another deletion operation.
Or we just keep that entry, it would take some space though and can acumulate to a larger space.
--Samik ganguly (talk) 10:30, 5 April 2012 (UTC)
thread_title:  Deletion of seperator value from index node 

message: Hello,
Quotation from the article: "(The root is also the single leaf, in this case.) This node is permitted to have as little as one key if necessary, and at most b."
Are you sure that the root node possible maximum number of keys as a leaf is b and not (b - 1) like any other "regular" leaf? 
Thank you.  — Preceding unsigned comment added by 217.128.106.129 (talk) 21:17, 10 November 2012 (UTC)
thread_title:  Maximum possible number of keys in the root node as a leaf 

message: I. Here it states, "A B+ tree can be viewed as a B-tree in which each node contains only keys (not key-value pairs)"
II. However, in the B tree article : "In the B+-tree, copies of the keys are stored in the internal nodes; the keys and records are stored in leaves"
Is is I, II, or neither?
=== A B+ tree is ===
A B+ tree is simply a B tree with data stored at the leaves instead of with the keys in the internal nodes. 
Although it is possible to link the leaf nodes as a single or double link list, that is not a requirement. You could also do that with other trees, but it's just cleaner and more elegant to do with B+ trees than most others 
There are misleading statements should be removed like the definition here that seems to be someone's inaccurate opinion coming from a typical variation.  132.160.49.90 (talk) 04:09, 27 March 2016 (UTC)
thread_title:  So, what is a B+tree? 

message: A B+ tree is simply a B tree with data stored at the leaves instead of with the keys in the internal nodes. 
Although it is possible to link the leaf nodes as a single or double link list, that is not a requirement. You could also do that with other trees, but it's just cleaner and more elegant to do with B+ trees than most others 
There are misleading statements should be removed like the definition here that seems to be someone's inaccurate opinion coming from a typical variation.  132.160.49.90 (talk) 04:09, 27 March 2016 (UTC)
thread_title:  A B+ tree is 

message: Hello fellow Wikipedians,
I have just added archive links to  on B+ tree. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive https://web.archive.org/20090912082150/http://1978th.net:80/tokyocabinet/ to http://1978th.net/tokyocabinet/
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
Cheers.—cyberbot IITalk to my owner:Online 22:42, 9 January 2016 (UTC)
thread_title:  External links modified 

message: Please double check me on this.  The text introducing the Algorithms section suggests that a node has "d" children.   The algorithm then suggests that the node contains keys  k_0 .. k_d.   That's d+1 keys.   That suggests there are d+2 children.  That's the first apparent bug.  
The pseudo code then indicates that for k<=k_0 one should visit p0.  That's reasonable, but if that's the case, then if k_{d-1} < k <= k_{d}, one should visit p_{d}.   If that's the case, then if k_d < k, one should visit p_{d+1}.  But that's not what the pseudocode suggests.  The last pseudocode case suggests visiting and p_d, not p_{d+1}.   That is the second apparent bug.   
Please double check me on this. Jasonnet (talk) 07:50, 27 October 2020 (UTC)
thread_title:  Bug in Pseudo Code ? 

message: The diagram is incorrect (the top node has too small a range) and also confusing. I had to look at many other visualizations on the internet to understand B+ Trees.
There are a few other issues with the diagram, IMO:
* The "next" pointers in the leaves being at the same level as the "data" slots make it look as though they are meant to be part of the "data" array
* The alignment of the boxes, while not bad, don't make it as clear as it could be that the sub-trees are the intervals of keys between each parent key
There is a great visualization tool here, which corrects both of these flaws:
* https://roy2220.github.io/bptree/visualization/#4,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10
I recorded a GIF to which I think is much more informative, perhaps we could replace or add this to the page to help other learners in the future?
GavinRay97 (talk) 17:10, 8 January 2023 (UTC)
replies: text: Hi, i posted the problem below. Since you visualized the algorithm with an even number for b (4) and I see a problem with odd values of b - maybe you could kindly verify or falsify my claim that the rules don't work for odd numbers. Thanks! 2.243.54.247 (talk) 06:08, 4 April 2023 (UTC)
thread_title:  Diagram 

message: In the example given with b=7 it seems to be impossible to construct a valid tree with 7 entries.
* For tree sizes from 0-6 the root node can point directly to the records. Fine
* For tree sizes >= 8 the data can be balanced between 2 or more leaf nodes.
* For tree size 7 a single root node cannot have all records as children, so it cannot be the only node of the tree. So we need a "regular" root node with at least 2 children. As each child requires at least 4 children, we need at least 8 records to construct the leaf pages.
(This problem seems to arise for b entries whenever b is an odd number.)
Am I missing something or does one of the restrictions be modified a little to accommodate that case?
2.243.54.247 (talk) 06:05, 4 April 2023 (UTC)
thread_title:  Root-Leaf node size