From 49e73991a5bce8ce19c185ef3b55e3d1e0c40027 Mon Sep 17 00:00:00 2001 From: KOIZUMI Satoru Date: Sun, 2 Feb 2025 23:20:30 +0900 Subject: [PATCH] respond to Saito-san's comment --- doc/src/sgml/limits.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/sgml/limits.sgml b/doc/src/sgml/limits.sgml index faae590a3b3..02c1271f4ad 100644 --- a/doc/src/sgml/limits.sgml +++ b/doc/src/sgml/limits.sgml @@ -233,7 +233,7 @@ Typically, this is only an issue for tables containing many terabytes of data; partitioning is a possible workaround. --> -各テーブルは、理論上最大2^32個の行外の値を格納できます。行外のストレージの詳細については、を参照してください。 +各テーブルは、理論上最大2^32個の行外の値を格納できます。行の外部への格納の詳細については、を参照してください。 この制限は、そのような各値を識別するために32ビットのOIDを使用することから生じています。 実際の制限は理論的な制限よりも大幅に低くなります。それは、OIDの空間が満杯になるにつれて、まだ空いているOIDを見つけるのに時間が掛かるようになり、INSERT/UPDATE文が遅くなるからです。 通常、これはテーブルにテラバイト単位のデータが含まれている場合にのみ発生する問題であり、パーティショニングが回避策として考えられます。