Shaun Cutts <shauncutts@factfiber.com> writes:
> Is there a reason besides “its bad design” to disallow tables with many
> columns?
There are numerous implementation problems you'd have to overcome.
There are illuminating comments in htup_details.h:
* MaxTupleAttributeNumber limits the number of (user) columns in a tuple.
* The key limit on this value is that the size of the fixed overhead for
* a tuple, plus the size of the null-values bitmap (at 1 bit per column),
* plus MAXALIGN alignment, must fit into t_hoff which is uint8. On most
* machines the upper limit without making t_hoff wider would be a little
* over 1700. We use round numbers here and for MaxHeapAttributeNumber
* so that alterations in HeapTupleHeaderData layout won't change the
* supported max number of columns.
and
* In any case, depending on column data types you will likely be running
* into the disk-block-based limit on overall tuple size if you have more
* than a thousand or so columns. TOAST won't help.
Also, in the past we've noted planner and executor behaviors that are
O(N^2) in the number of columns in a query result. I'm not sure those are
all gone, but if not you'd be in for some pain with very wide queries.
If someone were to throw lots of effort at the problem, and not care
about preserving on-disk database compatibility, no doubt all these
things could be dealt with. But I don't see it getting to the top of
the community's TODO list.
regards, tom lane
