First of all, good article explaining the basics of included columns.

Unfortunately, the space saving of 48.9% is completely wrong. Yes, you are saving 48.9% space in the intermediate levels (actually little less because of pointers to the next level) but that amounts to about 0.4% for the whole index! 0.4%! That's it. Not worth talking about since fragmentation will cost you much more.

Anyway, here are more details, somebody please check my math 🙂

Assume 8kB ~ 8000B per page (it's actually 8096 but this will make the math easier).

Assume a pointer to the next level is 4B (it is 6B but 4B will make it simpler).

Assume that a pointer to a table row is also 4B (that depends on the table, in most cases it's more than 4B).

Ignore any row overhead.

In any case, these assumptions give advantage to an index with included columns, so no harm done.

Let's take a table with 1,000,000 rows.

Full index

LEAF LEVEL: 1,000,000 leaves, 50B/leaf ==> 6,250 pages

INTERMEDIATE LEVEL: 6,250 nodes, 50B/node ==> 160 nodes/page ==> 40 pages

ROOT LEVEL: 40 nodes, 50B/node ==> 160 nodes/page ==> 1 page

Total# pages: 6,291

Index with included columns

LEAF LEVEL: 1,000,000 leaves, 50B/leaf ==> 160 leaves/page ==> 6,250 pages

INTERMEDIATE LEVEL: 6,250 nodes, 20B/node ==> 400 nodes/page ==> 16 pages

ROOT LEVEL: 16 nodes, 20B/node ==> 400 nodes/page ==> 1 page

Total# pages: 6,267

6,291 / 6,267 = 1.003829 ... ~ 1.004

Clearly, there are slight differences in the final number depending on the table size but no matter what, the number will be very similar for any number of rows.

Also, in Josef's example, the leaf node/index key was relatively small and therefore the number of intermediate nodes compared to the # leaf nodes was very small. With wider indexes, the number of intermediate nodes increases and so does the amount of saved space.