How can we foresee (and configure) B-Tree and R-Tree indexes width and depth in PostgreSQL? The B-Tree and the R-Tree are two similar index structures that PostgreSQL offers in its implementation.

Both structures can have at most m children per node and as other tree structures, children can have other children. However, in my test data, my structures are always in the form of a root node with many children i.e. just 2 levels. 

How can I understand better at which point will the structure's depth increase? What determines how many elements can be on the same level of a tree in terms of PostgreSQL? Is it possible to configure these or the m variable?
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.