Both structures can have at most
m children per node and as other tree structures, children can have other children.
The million dollar question there is what you mean when you say
m children. Math and algorithms in the abstract are concerned with purity: the name for that structure is a Binary Search Trees. Databases are concerned with concurrency and performance, they don't use Binary Search Trees (usually). PostgreSQL implementation of a B-tree isn't based on "children" but on index tuple size and fill factors. Simply, if you can fit more items on the page, you do that: it's called the Index Blocking Factor. The structure is called a B-Tree. Every level of the tree requires a block seek, so you want to do the most you can do to minimize the amount of blocks you must retrieve to complete the index operations. Further complicating matters, the size of the index tuple is variable, from the docs,
Lehman and Yao assume fixed-size keys, but we must deal with
variable-size keys. Therefore there is not a fixed maximum number of
keys per page; we just stuff in as many as will fit. When we split a
page, we try to equalize the number of bytes, not items, assigned to
each of the resulting pages. Note we must include the incoming item in
this calculation, otherwise it is possible to find that the incoming
item doesn't fit on the split page where it needs to go!
tldr; you have little control of the depth (outside of
fillfactor). The rows being indexed can result in a variable page size entry, and the depth is a factor of your block size and the index entry size.