<p>I'm not sure from the wording of your question if you are interested in set union or concatenation or both, or if you're only interested in persistent data structures as are common in OCaml or also in ephemeral structures.</p>

<p>An implementation of <a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.4454" rel="noreferrer">red-black trees with fingers is described by Heather D. Booth in a chapter from her thesis</a>. With fingers, a red-black tree of size n can be split into two trees of size p and q in amortized O(lg (min (p,q))) time and two red-black trees of size p and q can be concatenated in the same bound. Additionally, an element can be added or deleted at either end of an rb tree in amortized O(1) time. With these operations, it is possible to achieve amortized O(p lg(q/p)) time set union (for p &lt; q), which is information-theoretically optimal. Perhaps the key idea to get these bounds is the reversal of the child pointers on the left and right spines.</p>

<p>The bounds above are amortized in the traditional sense. For a functional language like OCaml, one might wish to have bounds that apply when a data structure is used persistently. I do not think Booth's description will achieve all of those bounds when the trees are used persistently. For example, insertion at a finger can take &omega;(1) recolorings. This might be solved via the <a href="http://www.cs.cmu.edu/~sleator/papers/making-data-structures-persistent.pdf" rel="noreferrer">lazy recolorings discussed in Driscoll et al.'s "Making Data Structures Persistent"</a>.</p>

<p>On the other hand, I think Booth's analysis might show that concatenation is still O(lg (max (p,q))) even when used persistently. I'm less optimistic about the set union bound.</p>

<p>Set operations with asymptotically optimal time bounds are possible in a functional setting. Those <a href="http://www.soi.city.ac.uk/~ross/papers/FingerTree.pdf" rel="noreferrer">described by Hinze &amp; Paterson</a> achieve the bounds in an amortized (but persistent) sense, the <a href="http://www.cs.cmu.edu/afs/cs/project/pscico/pscico/papers/fingertrees/main.pdf" rel="noreferrer">treaps described by Blandford &amp; Blelloch achieve the bounds in a randomized sense</a>, and those <a href="http://www.math.tau.ac.il/~haimk/papers/loglog23.ps" rel="noreferrer">described by Kaplan &amp; Tarjan</a> achieve them in worst-case time. The latter also offer O(lg lg (min(p,q))) concatenation, though Hinze &amp; Paterson are dubious of that claim. These trees are not a direct answer to your question, which is specific to red-black trees, but they hopefully give a flavor of what is possible, and the H&amp;P paper includes code, and <a href="http://mattam.org/research/russell/fingertrees.en.html" rel="noreferrer">has been verified correct using Coq</a>, which can extract to OCaml code.</p>

<p>Two more pointers you might be interested in: <a href="http://www.cs.au.dk/~gerth/pub/esa06trees.html" rel="noreferrer">Brodal et al. presented search trees with O(lg n) find, insert, and delete and O(1) concat even in a functional setting</a>. Additionally, <a href="http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-035.pdf" rel="noreferrer">Atallah et al. claim to describe a red-black tree that has amortized O(1) concat (presumably ephemerally only)</a>, but <a href="http://www.ics.uci.edu/~goodrich/pubs/esa-maxima.pdf" rel="noreferrer">Buchsbaum and Goodrich claim that there are several flaws in that structure</a>.</p>

<p>One final note about the utility of red-black trees: in one of the comments on one of the answers to this question, you say:</p>

<blockquote>
  <p>The only advantage of a red-black tree is that the auxiliary information (red or black) is only 1-bit per branch. By adding height, you've lost that advantage and might as well just use a height-balanced tree instead.</p>
</blockquote>

<p>There are other advantages as well. For instance, some data structures used in computational geometry are based on binary search trees but have a high cost of tree rotation. <a href="http://dx.doi.org/10.1016/0020-0190(83)90099-6" rel="noreferrer">Red-black trees can be rebalanced in at most 3 rotations per insert and delete</a>, while <a href="https://arxiv.org/abs/1506.03528" rel="noreferrer">AVL trees can take &Omega;(lg n) rotations for these operations</a>. <a href="http://archive.cs.uu.nl/pub/RUU/CS/techreps/CS-2001/2001-09.pdf" rel="noreferrer">As Ralf Hinze noticed</a>, <a href="http://www.eecs.usma.edu/webs/people/okasaki/jfp99.ps" rel="noreferrer">Okasaki's rebalancing scheme for red-black trees</a> (code available in <a href="http://www.eecs.usma.edu/webs/people/okasaki/pfds-sml.tar.gz" rel="noreferrer">ML</a>, <a href="http://www.eecs.usma.edu/webs/people/okasaki/pfds-haskell.tar.gz" rel="noreferrer">Haskell</a>, <a href="http://www.eecs.usma.edu/webs/people/okasaki/sigcse05/index.html" rel="noreferrer">Java, and Ada</a>) does not offer the same bound, and can end up doing &Omega;(lg n) rotations on insertion. (Okasaki does not present deletion.)</p>

<p>Additionally, height-balanced search trees (and even AVL trees) can be stored so as to use only one bit of balance information per node. Some trees have only two possible balance positions at each node, like one-sided height-balanced trees, but trees with up to four possible balance positions per node can store one bit of balance information in each child, as <a href="http://linkinghub.elsevier.com/retrieve/pii/0020019078900054" rel="noreferrer">initially explained by Brown</a> and later <a href="http://www.cs.princeton.edu/~sssix/papers/rb-trees.pdf" rel="noreferrer">expanded upon by Haeupler et al.</a></p>

<p><b>Edit:</b></p>

<p>In answer to your specific query at the end of your question, here is a description of an algorithm for concatenating two red-black trees. It takes O(lg(max(|L|,|R|))) time, which is too long to get the asymptotically optimal union time I describe above. For comparison, I expect that <a href="http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/stdlib/set.ml?rev=6694&amp;view=markup" rel="noreferrer">the "join" implementation for AVL sets in OCaml's stdlib</a> gets O(h1-h2) performance, where h1 is the height of the taller tree, though it actually joins two AVL trees given an element that fits between them, while the algorithm below has to find and remove that mortar element from one of its arguments. You could avoid that by only storing elements at the leaves, as in a B+ tree, but that has a space penalty of having to keep a bunch of pointers to elements in the non-leaf nodes to guide search. In any case, it wouldn't make join constant time for trees of the same height like the AVL join code in the OCaml stdlib, since you would still have to calculate the black height of each tree, as explained below.</p>

<p>Given two non-empty red-black trees L and R, we will produce a new red-black tree that is the concatenation of L and R. This will take time proportional to O(lg
(max(|L|,|R|))), where |L| denotes the number of nodes in L.</p>

<p>First, remove the largest element from L, c. Next, find the black height of L and R. By "black height", I mean the number of black nodes on any path from the
root to a leaf. By the red-black tree invariants, this is constant on all paths of any given tree. Call L's black height p and R's black height q, and assume
w.l.o.g. p &le; q.</p>

<p>From the root of R, follow left children until arriving at a black node R' with height p. Make a new red tree C with root element c, left child L and right
child R'. Since L is a red-black tree on its own, its root is black, and the color invariants are not violated at or below C. Furthermore, the black height of C
is p.</p>

<p>However, we cannot simply splice C back into R in place of R'. First, if p = q, R' is R, yet C has a red root. In this case, simply recolor the root of C black. This is your
new concatenated tree.</p>

<p>Second, if R' is not the root, it may have a red parent. Red parents are not permitted to have red children, so we must rebalance. Here we just apply Okasaki's rebalancing
scheme all the way up the spine between R' (now replaced with C) and the root of R.</p>

<p>There are two possible cases. If C has no grandparent, color C's parent black. The tree is now valid.</p>

<p>If C has a grandparent, it must be black and of black height p+1, since C's parent is red. Replace C's grandparent with a new red tree, the root of which is the root of C's parent, the
left child of which is C, recolored black, and the right child of which is a black tree that consists of C's sibling, C's grandparent's root, and C's uncle, in
that order. This doesn't increase the black height of C's grandparent, but it changes its color to red, which might make it a root or a red child of a red
parent, so we have to rebalance again, and so on all the way up the tree</p>

<ul>
<li>Finding the black height of both trees : O(lg |L|) + O(lg |R|)</li>
<li>Tracing down R to the right spot: O(lg |R| - lg |L|)</li>
<li>Rotations all the way back up to the root: O(lg |R| - lg |L|)</li>
</ul>

<p>None of these is greater than O(lg |R| + lg |L|) = O(lg (max(|L|,|R|)))</p>

<p>To make this O(lg (min(|L|,|R|))), first reverse the spine pointers. Then you don't need the black height of the larger tree, you only need to count black spine nodes until one tree runs out of spine. Then, use the original (not Okasaki's) rebalancing scheme to make sure you only rebalance O(1) nodes. Finally, mark the rest of the spine that doesn't need rebalancing for lazy recoloring if necessary later.</p>
Concatenating red-black trees
<p>The OCaml standard library has a wonderful <code>Set</code> implementation that uses a very efficient divide-and-conquer algorithm to compute the <code>union</code> of two sets. I believe it takes whole subtrees (not just single elements) from one set and inserts them into the other set, rebalancing when necessary.</p>

<p>I'm wondering if this requires the height information that is kept in the AVL tree that OCaml uses or if this is also possible with red-black trees. For example, is it possible to concatenate a pair of red-black trees more efficiently than simply iterating over the second tree appending its elements to the end of the first tree?</p>