Actually, thinking about this issue a bit more, I'm wondering: what is it we expect to win here?
Because we will still need to allocate one FlyweightColumn object per actual column. So in terms of sheer number of allocated objects, we'll have the same number (in fact we'll even have marginally more ojbects since we'll have to allocate the FlyweightColumns names, values and timestamps arrays).
Now it's true that the memory layout will be slightly different, with the FlyweightColumn objects being slightly smaller than their Column counterpart (though overall we won't allocate less memory), but I'm not sure it makes much difference for the GC since the size difference is relatively minor. And on the other side, the circular dependency of FlyweightColumns to it's child FlyweightColumn might make the job of the GC a bit harder (it's more links to explore). Overall, it's far from obvious to me that it would improve things in a measurable way.
And doing that would also mess a bit with the ColumnSerializer, as we would want it to create a flyweightColumn right away, meaning that it's not just an alternative ISortedColumn implementation, the abstraction would leak out.
So am I missing something here and not understanding that idea at all?