Re: Maximum row size

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Devrim GÜNDÜZ <devrim(at)CommandPrompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Maximum row size
Date: 2007-08-13 13:30:45
Message-ID: 4287.1187011845@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> ... it's kind
> of pie-in-the-sky since it depends on every column being toasted (and not
> compressed). It's much more normal to have some columns be quite large and
> others more normal sized or different data types.

Yeah. I think those numbers should simply be removed from the
discussion entirely, because they are bogus. There is no real-world
situation where someone is going to put 1Gb into each and every field of
a row. The limits that should be stated are 1Gb per column and 250-1600
columns per table --- let the readers draw their own conclusions from
those.

As Greg notes, the 400-column figure came from presuming that every
column gets toasted out-of-line; but that's not totally realistic
either. Furthermore, we have some untoastable types that are wider
than a toast pointer. The worst case seems to be 32 bytes for box,
line, and lseg (I ignore "name" which is stated not to be intended
for general-purpose use). If you made a table of only "box" columns
you could get at most a bit over 250 of them on a standard-size page.
So I think that's what we should quote as the lower bound.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-08-13 13:34:07 Re: strange behaviour of parser - numeric domain doesn't work phantom
Previous Message Michael Meskes 2007-08-13 13:09:13 8.3 freeze/release