Re: State of Beta 2

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: Sean Chittenden <sean(at)chittenden(dot)org>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Vivek Khera <khera(at)kcilink(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: State of Beta 2
Date: 2003-09-12 15:11:25
Message-ID: 200309121511.h8CFBPh20344@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Manfred Koizar wrote:
> On Fri, 12 Sep 2003 10:22:32 -0400 (EDT), Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
> wrote:
> >> This 1600 column limit has nothing to do with block size. It is
> >> caused by the fact that a heap tuple header cannot be larger than 255
> >> bytes, so there is a limited number of bits in the null bitmap.
> >
> >Are you sure.
>
> No, never! ;-)
>
> Sollte einer auch einst die vollkommenste Wahrheit verk?nden,
> Wissen k?nnt' er das nicht: Es ist alles durchwebt von Vermutung.
>
> For even if by chance he were to utter the final truth,
> He would himself not know it: For it is but a woven web of guesses.
> -- Xenophanes, translation by K. R. Popper
>
> But in this case I have htup.h on my side:
>
> /*
> * MaxTupleAttributeNumber limits the number of (user) columns in a tuple.
> * The key limit on this value is that the size of the fixed overhead for
> * a tuple, plus the size of the null-values bitmap (at 1 bit per column),
> * plus MAXALIGN alignment, must fit into t_hoff which is uint8. On most
> * machines the upper limit without making t_hoff wider would be a little
> * over 1700. We use round numbers here and for MaxHeapAttributeNumber
> * so that alterations in HeapTupleHeaderData layout won't change the
> * supported max number of columns.
> */
> #define MaxTupleAttributeNumber 1664 /* 8 * 208 */
>
> /*----------
> * MaxHeapAttributeNumber limits the number of (user) columns in a table.
> * This should be somewhat less than MaxTupleAttributeNumber. It must be
> * at least one less, else we will fail to do UPDATEs on a maximal-width
> * table (because UPDATE has to form working tuples that include CTID).
> * In practice we want some additional daylight so that we can gracefully
> * support operations that add hidden "resjunk" columns, for example
> * SELECT * FROM wide_table ORDER BY foo, bar, baz.
> * In any case, depending on column data types you will likely be running
> * into the disk-block-based limit on overall tuple size if you have more
> * than a thousand or so columns. TOAST won't help.
> *----------
> */
> #define MaxHeapAttributeNumber 1600 /* 8 * 200 */

Oh, interesting. I thought it was based on the maximum number of
columns we could pack into a block. I realize that our limit could be
much less than 1600 if you pick wide columns like TEXT.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-09-12 15:16:58 Re: State of Beta 2
Previous Message Manfred Koizar 2003-09-12 15:08:40 Re: State of Beta 2