すべての値が36文字の場合、char vs varcharを使用すると、インデックスルックアップは著しく高速になりますか

すべてのテーブルのプライマリキーにハッシュベースの生成されたIDを使用するレガシースキーマ（免責事項！）があります（多数あります）。このようなIDの例は次のとおりです。

922475bb-ad93-43ee-9487-d2671b886479

このアプローチを変更する可能性はありませんが、インデックスアクセスのパフォーマンスは低下します。これが無数にある理由は別として、多くのテーブルのすべてのid値が正確に36文字の長さであるにもかかわらず、列タイプはvarchar(36)でなく 、最適ではないように思われることが1つありchar(36)ます。

固定長に列の型を変更することだろうchar(36)任意の提供の重要なインデックスページなどあたりのエントリの数が非常に少ないの増加を超えて、インデックスのパフォーマンス上の利点？

つまり、固定長型を扱う場合、可変長型よりもpostgresの方がはるかに高速ですか？

わずかなストレージの節約については言及しないでください-列に変更を加えるために必要な手術と比較しても問題にはなりません。

いいえ、すべてではありませんゲイン。マニュアルは明示的に述べています：

ヒント：これら3つのタイプの間にパフォーマンスの違いはありません。ただし、空白が埋め込まれたタイプを使用する場合のストレージスペースの増加、および長さ制限のある列に格納する場合の長さをチェックするためのいくつかの余分なCPUサイクルは除きます。ながら、character(n)いくつかの他のデータベース・システムのパフォーマンス上の利点を有し、PostgreSQLのそのような利点がありません。実際にcharacter(n)は、追加のストレージコストのために、通常3つの中で最も遅いです。ほとんどの場合text 、character varying代わりに使用する必要があります。

大胆な強調鉱山。

char(n)ほぼ時代遅れの、役に立たないタイプです。に固執するvarchar(n)。長さを強制する必要がない場合、varcharまたはtext少し速くなる場合。差を測定することはできません。

すべての文字列の長さが36個の文字を正確にしている場合も、ありません何のいずれかの方法ではなく、さらに微小の1を保存するストレージ。どちらもディスクとRAMでまったく同じサイズです。pg_column_size()（式およびテーブル列で）テストできます。

関連：

• 文字列を保存するためにデータ型「テキスト」を使用することの欠点はありますか？

あなたは他のオプションを要求しませんでしたが、私は2つ言及します：

1. COLLATION- 「C」照合を使用してDBを実行している場合を除き。照合はしばしば見落とされ、場合によっては高価になります。あなたの文字列は自然言語では意味がないように見えるので、COLLATIONルールに従うことはおそらく意味がありません。関連：

   • 「最新の対応する行」を効率的に取得するにはどうすればよいですか？
   • インデックスを使用していない関数内で実行しますか？

   （特に）の効果を比較する広範なベンチマーク COLLATE "C"パフォーマンスへの：

   • 結合されたテーブルの列によるクエリの順序が遅い

2. UUID、明らかに。文字列は疑いなくUUID（32桁の16進数と4つの区切り文字）のように見えます。これらを実際のuuidデータ型として保存する方がはるかに効率的です。これは複数の方法で高速であり、 16バイトしか占有しません-どちらかまたは（区切り文字なしで保存された32個の定義文字だけで）RAMの 37バイトとは対照的に、 33ディスク上のバイト。ただし、多くの場合、アライメントパディングはいずれの場合も 40バイトになります。）は、データ型にも無関係です。char(36)varchar(36)COLLATIONuuid

   SELECT '922475bb-ad93-43ee-9487-d2671b886479'::uuid

   これは役に立つかもしれません（最後の章）：

   • テキスト表現の16進数を10進数に変換します

   こちらもご覧ください：

   • varchar（n）のオーバーヘッドは何ですか？
   • MD5フィールドに最適なデータ型は何ですか？