表格大小与页面布局 [英] Table size with page layout

查看:81
本文介绍了表格大小与页面布局的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在Oracle Linux Server版本6.3上使用PostgreSQL 9.2。

I'm using PostgreSQL 9.2 on Oracle Linux Server release 6.3.

根据存储布局文档,页面布局保持:


  • PageHeaderData(24字节)

  • n项目的点数(索引项/表项)AKA ItemIdData(4字节)

  • 可用空间

  • n个项目数量

  • 特殊空间

  • PageHeaderData(24 byte)
  • n number of points to item(index item / table item) AKA ItemIdData(4 byte)
  • free space
  • n number of items
  • special space

我测试了一些公式来估计预期的表格大小(TOAST概念可能会被忽略)。

I tested it to make some formula to estimate table size anticipated...(TOAST concept might be ignored.)

postgres=# \d t1;

                      Table "public.t1"
    Column    ','         Type         ','         Modifiers
---------------+------------------------+------------------------------
 code          |character varying(8)    |not null
 name          |character varying(100)  |not null
 act_yn        |character(1)            |not null default 'N'::bpchar
 desc          |character varying(100)  |not null
 org_code1     |character varying(3)    |
 org_cole2     |character varying(10)   |

 postgres=# insert into t1 values(
'11111111', -- 8
'1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111', <-- 100
'Y',
'1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111', <-- 100
'111',
'1111111111');

postgres=# select * from pgstattuple('t1');
 table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
      8192 |           1 |       252 |          3.08 |                1 |            252 |               3.08 |       7644 |        93.31
(1 row)

为什么 tuple_len 252而不是249? (所有列的最大长度的222字节PLUS
元组标题的27字节,后跟可选的空位图,可选对象ID字段和用户数据)

Why is tuple_len 252 instead of 249? ("222 byte of all column's maximum length" PLUS "27 byte of tuple header followed by an optional null bitmap, an optional object ID field, and the user data")

3个字节来自哪里?

我的公式有问题吗?

推荐答案

您的计算在几个点被关闭。

Your calculation is off at several points.


  • 存储大小 varchar text 是(引用手册这里):

  • Storage size of varchar or text is (quoting the manual here):

存储短字符串(最多126个字节)的要求是 1个字节
加上实际字符串
,其中包含字符
的空格填充。较长的字符串具有4字节的开销而不是1。
系统自动压缩长字符串,因此磁盘上的
物理需求可能会较小。

The storage requirement for a short string (up to 126 bytes) is 1 byte plus the actual string, which includes the space padding in the case of character. Longer strings have 4 bytes of overhead instead of 1. Long strings are compressed by the system automatically, so the physical requirement on disk might be less.

粗体强调我的评论中的问题。

Bold emphasis mine to address question in comment.

  • The HeapTupeHeader occupies 23 bytes, not 27 bytes.

由于数据对齐(8位数),填充1个字节,用于这种情况下的NULL位掩码。

1 byte of padding due to data alignment (multiple of 8), which is used for the NULL bitmask in this case.

没有填充类型 varchar

所以,实际计算是:

        23    -- heaptupleheader
     +   1    -- NULL bit mask (or padding if all columns are NOT NULL)
     +   8    -- columns
     + 100 
     +   1 
     + 100 
     +   3 
     +  10 
     +   6    -- 1 byte overhead per varchar column, 6 columns

- > 252 字节。

我写了几个相关的答案,你可以找到大部分链接到这是一个(查看右侧的链接列表)。

I wrote a couple of related answers, you can find most of them linked to this one (look at the link list to the right).

这篇关于表格大小与页面布局的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆