Bruce, I think section 4.6 of the FAQ is a tad on the short and overly
optimistic side. Here's a set of more precise statements ...
4.6) What is the maximum size for a row, table, database?
Maximum size for a database?
Effectively unlimited, although you may see performance problems with
more than a few thousand tables in a database, depending on how
gracefully your filesystem copes with directories containing many files.
Maximum size for a table?
2G blocks, hence 16 to 64 terabytes depending on the BLCKSZ
configuration constant. (If someone were to run around and make sure
all the block-number arithmetic is unsigned, we could claim 4G blocks,
but I think it's not all unsigned now...)
Maximum size for a row?
See limits on field size and number of columns.
Maximum size for an individual field value?
Field values are limited to 1Gb, and in practice are more tightly
limited by memory/swap space available to a backend; a field value that
is a large fraction of the maximum process memory size will probably
cause out-of-memory failures.
Maximum number of columns in a table?
1600. In practice probably quite a bit less, even with TOAST, since the
master tuple still has to fit in a block. If all the columns are large
(toastable) then at most you could fit about 250 columns with BLCKSZ=8K,
since an out-of-line TOAST value pointer takes 32 bytes. On the other
hand, 1600 int4 columns would fit easily.
Maximum number of rows in a table?
No specific limit. Note however that the COUNT() function currently
uses an int4 counter, so will give bogus results for more than 2G rows.
Maximum number of indexes on a table?
No limit.
regards, tom lane
