"Clark C. Evans" <c...@clarkevans.com> writes: > What would be most helpful though is if the answer to > this question stop being an attack on the business > requirement analysis, database design skills, and/or > sanity of the requester. It's a limitation of > PostgreSQL's implementation; a deliberate performance > trade-off that is infeasible to change.
Just for the record: I don't think its *infeasible* to change it. What I'm saying is that it would be a bad tradeoff for the vast majority of users. I could imagine accepting a patch that provides a compile-time option to change the limit. The core of it would be something like + #ifdef SUPPORT_RIDICULOUSLY_MANY_COLUMNS + uint16 t_hoff; /* sizeof header incl. bitmap, padding */ + #else uint8 t_hoff; /* sizeof header incl. bitmap, padding */ + #endif plus whatever other fallout ensues elsewhere. But somebody would have to step up to develop and test such a patch, and keep on testing it to ensure no bit-rot sets in, because it seems very unlikely that any mainstream distributions would ever choose to enable the option. I don't think any of the core developers have any interest in hacking on this; we have bigger fish to fry. So it'd be a matter of someone scratching their own itch. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general