Re: State of Beta 2

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: State of Beta 2
Дата
Msg-id 200309121511.h8CFBPh20344@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: State of Beta 2  (Manfred Koizar <mkoi-pg@aon.at>)
Список pgsql-general
Manfred Koizar wrote:
> 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 */

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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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

Предыдущее
От: Manfred Koizar
Дата:
Сообщение: Re: State of Beta 2
Следующее
От: Tom Lane
Дата:
Сообщение: Re: State of Beta 2