wieck@debis.com (Jan Wieck) writes:
> I think that only a combination of LONG attributes and split
> tuples will be a complete solution.
If we can do a good job with long attributes, I really think we
will not need to have split tuples too.
You'd be able to put perhaps 400 LONG attributes into an 8K tuple,
more than that if they are float8 or int or bool attributes.
If someone needs tables with even more columns than that, they
could bump BLCKSZ up to 32K and quadruple the number of columns.
How many people are really going to be bumping into that limit?
Is it worth the work and reliability risk to support long tuples
for a few applications that are about three sigmas out on the bell
curve? I doubt it.
I think the effort this would take would be *much* more profitably
spent on tuning the LONG-attribute support. If we can make that
fast and robust, we will have very few complaints.
regards, tom lane