如何计算Postgresql中的最大列数

我想知道计算postgresql表中最大列数的正确方法是什么。他们的网站上写着：

表250-1600中的最大列数取决于列类型

---

因此，根据列类型，如何确定最大列数？

您需要了解PostgreSQL物理数据存储的详细信息

您可能知道，默认的PostgreSQL块大小是8kB（8192字节）。您还应该知道，在PostgreSQL表中，行不能跨越块边界。 这已经为您提供了8192字节的大小限制。但是

从上面的页面布局来看，

PageHeader

也有开销，在当前PostgreSQL版本中为24字节。剩下8168个字节。但是

还有

ItemIdData

，它是指针数组。让我们假设这个页面上只有一条记录，因此这个条目只占用4个字节（1个条目）。剩下8164字节。但是

每条记录也有一个

记录头

，已知它占用23个字节。剩下8141个字节。但是

在

RecordHeader

后面还有一个

NULL

-位图，但假设我们已经用

非NULL

约束定义了所有列。这里也是8141字节。但是

有这样一件事-

MAXALIGN

。看一看。 我们这里说的是偏移量

24+4+23=51

。 现在，一切都取决于系统上此参数的值

若它是32位1，那个么偏移量将与52对齐，这意味着我们又浪费了一个字节

若它是64位1，那个么偏移量将与54对齐，这意味着我们又浪费了3个字节。 我的系统是64位1，所以我假设剩下8138字节

这就是我们剩下的空间。现在，一切都取决于我们选择的列的类型以及它们是如何组合在一起的（请记住

maxallign

thing）。让我们对所有列使用

int2

。简单的计算表明，我们应该能够压缩这种类型的4069列：所有列

notnull

和相同类型的列

简单脚本：

echo“创建表tab4069（“>tab4069.sql
对于美元中的数字（seq-f“%04g”14069）；是否
echo“col$num int2 not null”，>>tab4069.sql；完成
echo“主键（col0001））；”>>tab4069.sql

尽管如此，如果尝试创建此表，仍会遇到以下错误：

错误：表最多可以有1600列

稍微搜索一下，我们就得到了答案（第23到47行）：

有很多可变长度类型，它们执行1或4字节+实际值中某些字节数的固定开销。这意味着在获得实际值之前，您永远不会预先知道记录将占用多少空间。当然，这些值可以通过单独存储，但通常是更大的值（总长度为2kB）

请查阅，以了解用于固定长度类型的空间。您还可以检查任何类型的函数输出，特别是复杂类型的函数，如数组、

hstore

或

jsonb

---

但是，如果您想对这个主题有一个更全面的了解，就必须深入了解更多细节。

在考虑哪些列是稳定的时，还需要处理存储类的问题。哇。。信息量很大。然而，在我能理解你所写的一切之前，我必须掌握postgresql技术的最新进展。@vyegorov的回答很好地给出了技术细节。不过，我想指出，如果您担心达到列计数限制，那么您的模式中可能存在一些设计问题。在一个适当规范化的模式中，即使是250列也应该是非常罕见的。（对于动态创建的结果集，Pg可以处理超过250-1600 cols的范围，它仅在磁盘存储上限制该值。）

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