人工的なsmallintを追加すると思います テーブルが慎重に設計されている場合、主キーはストレージスペースの点で安価になります。
smallint character(10)が2バイトかかるのに対し、 （これは、直感に反して、varlena ）ASCII文字を含む場合、14バイトを消費します。
表では、余分な2バイトは無駄になりますが、主キー列にインデックスがあることを忘れないでください。したがって、インデックス付きの値は実際には2回保存されます。1回はテーブルに、もう1回はインデックスに保存されます。
簡単にするために、タプルヘッダーやその他のオーバーヘッドは無視しましょう。
-
ISBNを主キーとして使用すると、テーブル行ごとに14バイトの追加料金がかかります。
-
smallintを追加する 主キーはテーブルに2バイト、インデックスに2バイトを追加し、合計4バイトを追加します。
したがって、 smallintを追加します 主キーはスペースを節約する必要があります 。
配置の問題を無視しないでください。すべてのデータ型は、特定の2の累乗の倍数であるメモリアドレスに格納されます。これは、プロセッサのアーキテクチャで必要です。 smallint 通常、配置2、characterがあります 配置は1ですが、たとえばtimestamp 配置は8です。
したがって、テーブルが次のように定義されている場合
CREATE TABLE book (
id smallint PRIMARY KEY,
issue_time timestamp with time zone,
isbn character(10)
);
その場合、テーブルデータは次のようになります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
id padding issue_time
行は8バイトの境界で整列され、idの場合は末尾から6バイトになります。 issue_timeの先頭まで 空の「パディングバイト」になります。
したがって、それを最大限に活用するには、列を定義する順序を検討する必要があります。
これらすべてが実際にはあまり関係がない理由：
5000または10000エントリのテーブルは、何があっても小さいです。
ここでスペースの最適化に費やされたとしても、せいぜい不必要なマイクロ最適化です。
しかし、計画テーブルの賢いアイデアは後で簡単に裏目に出る可能性があります。予想とは異なり、テーブルに70000冊の本を保存したい場合は、smallint 負のidを許可しても、十分ではありません s。主キーのデータ型を変更する必要がある場合に耐えなければならない苦痛と、ライブシステムでそれを参照するすべての外部キーは、巧妙な最適化によって約100KBを節約することで得られる喜びをはるかに上回ります。