3

Oracle Linux Server リリース 6.3 で PostgreSQL 9.2 を使用しています。

ストレージ レイアウトのドキュメントによると、ページ レイアウトには以下が保持されます。

  • PageHeaderData(24バイト)
  • n アイテムへのポイント数(インデックスアイテム/テーブルアイテム) AKA ItemIdData(4バイト)
  • フリースペース
  • n 個のアイテム
  • 特別な空間

予想されるテーブルサイズを見積もる式を作成するためにテストしました...（TOASTの概念は無視される可能性があります。）

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_len249 ではなく 252 なのですか? (「すべての列の最大長の 222 バイト」に加えて、「オプションのヌル ビットマップ、オプションのオブジェクト ID フィールド、およびユーザー データが続く 27 バイトのタプル ヘッダー」)

3バイトはどこから来たのですか？

私の式に何か問題がありますか？

4

1 に答える 1

5

あなたの計算はいくつかの点で外れています。

短い文字列 (最大 126 バイト) のストレージ要件は、1 バイトに実際の文字列を加えたもので、これには文字の場合のスペース パディングが含まれます。より長い文字列には、1 ではなく 4 バイトのオーバーヘッドがあります。長い文字列はシステムによって自動的に圧縮されるため、ディスク上の物理的な要件は少なくなる可能性があります。

コメントで質問に対処するための大胆な強調鉱山。

  • HeapTupleHeaderは23 バイトを占有します。ただし、各タプル (「アイテム」 - 行またはインデックス エントリ) には、データ ページの先頭にアイテム識別子があり、合計で前述の 27 バイトになります。実際のユーザー データはMAXALIGN各アイテムの先頭から の倍数で始まり、アイテム識別子はこのオフセットと実際の「タプル サイズ」に対してカウントされないため、この区別は重要です。

  • この場合、NULL ビットマップに使用される、データ配置 (8 の倍数) による 1 バイトのパディング。

  • タイプのパディングなしvarchar(ただし、上記の追加バイト)

したがって、実際の計算 (すべての列が最大値まで入力された状態) は次のとおりです。

    23    -- heaptupleheader
 +   1    -- NULL bitmap (or padding if row has NO null values)
 +   9    -- columns ...
 + 101 
 +   2 
 + 101 
 +   4 
 +  11
-------------
   252 bytes

 +   4    -- item identifier at page start

関連している：

これらの回答の右側にあるリンク リストには、さらに多くの回答があります。

于 2012-11-23T09:16:54.857 に答える