Re: State of Beta 2

Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Re: State of Beta 2
Дата
Msg-id amm3mvgg5hi73rp2qv1arlggd9qumhji4l@email.aon.at
обсуждение исходный текст
Ответ на Re: State of Beta 2  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: State of Beta 2  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-general
On Fri, 12 Sep 2003 10:22:32 -0400 (EDT), Bruce Momjian <pgman@candle.pha.pa.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

В списке pgsql-general по дате отправления:

Предыдущее
От: "scott.marlowe"
Дата:
Сообщение: Re: selecting random rows
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: State of Beta 2