Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update limits for 17.0 #3170

Merged
merged 3 commits into from
Feb 8, 2025
Merged

update limits for 17.0 #3170

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
62e2592
update limits for 17.0
koizumistr Nov 30, 2024
49e7399
respond to Saito-san's comment
koizumistr Feb 2, 2025
c645ad0
respond Saito-san's comment again
koizumistr Feb 7, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 4 additions & 5 deletions doc/src/sgml/limits.sgml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -233,10 +233,9 @@
Typically, this is only an issue for tables containing many terabytes
of data; partitioning is a possible workaround.
-->
《機械翻訳》各テーブルは、理論上最大2^32個の直線外値を格納できます。
直線外ストレージの詳細については、<xref linkend="storage-toast" />を参照してください。
この制限は、そのような各値を識別するために32ビットのoidを使用することから生じる。
より小さいスペースが満杯になると、まだoidであるoidを見つけるのにコストがかかり、ダウンINSERT/更新ステートメントの速度が低下する可能性があるため、実際の限界は理論的な限界よりも大幅に低くなります。
フリー通常、これはテーブルにテラバイト単位のデータが含まれている場合にのみ発生する問題であり、パーティショニングを使用することで回避できます。
各テーブルは、理論上最大2^32個の行外の値を格納できます。行外の格納の詳細については、<xref linkend="storage-toast" />を参照してください。
この制限は、そのような各値を識別するために32ビットのOIDを使用することから生じています。
実際の制限は理論的な制限よりも大幅に低くなります。それは、OIDの空間が満杯になるにつれて、まだ空いているOIDを見つけるのに時間が掛かるようになり、INSERT/UPDATE文が遅くなるからです。
通常、これはテーブルにテラバイト単位のデータが含まれている場合にのみ発生する問題であり、パーティショニングが回避策として考えられます。
</para>
</appendix>