Re: State of Beta 2

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
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:08:40
Message-ID: amm3mvgg5hi73rp2qv1arlggd9qumhji4l@email.aon.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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 */

Servus
Manfred

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2003-09-12 15:11:25 Re: State of Beta 2
Previous Message scott.marlowe 2003-09-12 14:57:36 Re: selecting random rows