Shaun Cutts <shauncutts@xxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
