Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> The total row size must be under 8k, so that limits the number columns
> to a row by minimum size requirements (you can't fit 10k ints for
> example), but otherwise I don't know of anything for columns.
There is a limit of 1600 columns per table. (This is driven by the
fact that tuple header + null-values bitmap must fit into 255 bytes;
we could relax it by increasing t_hoff from uint8 to uint16, but I've
never yet heard anyone complain about it...)
> I don't know of a number of row in table limit, the system breaks
> up heap files to get around filesystem limits, probably disk space and
> performance related (make sure you have indexes and are using queries
> that use them).
AFAIK there's no direct limit on number of rows, although you would
see interesting misbehavior from count() with more than 2G rows, since
count() returns an int4 result. Table size is limited to either 2G or
4G blocks (not sure if we are careful to do BlockNumber arithmetic
unsigned or not), so either 16 or 32 terabytes per table at the default
blocksize of 8K, up to 64/128TB at blocksize 32K.
As you say, performance issues are probably going to cause more of a
problem than these theoretical limits, at least for a few more years ;-)
> The length of views and procedure text is limited
> since a format of those need to fit into a database row. The
> text length limit for indexes is approximately 2700 bytes and that
> might be the procedure length.
That was the procedure-text length limit in 6.5, but 7.0 doesn't keep
any indexes on procedure bodies, so in 7.0 you can have procedures
approaching 8K.
Row-length-related limits, including that one, should be largely solved
by 7.1's TOAST feature, although you'll still see a limit on number of
columns per table. TOAST only helps on column types that can be
sizable; for example, TOAST can't do anything with a float8 column,
and so you still won't be able to put >1000 float8 columns in one
table...
regards, tom lane
