Insertion into a <acronym>GIN</acronym> index can be slow due to the likelihood of many keys being inserted for each item. So, for bulk insertions into a table it is advisable to drop the GIN index and recreate it after finishing bulk insertion. 各項目に対して多くのキーが挿入される可能性がありますので、GINインデックスへの挿入は低速になることがあります。 ですので、テーブルに対する大量の挿入では、GINインデックスを削除し、大量の挿入が終わった段階で再作成することを勧めます。
When <literal>fastupdate</literal> is enabled for <acronym>GIN</acronym>
(see <xref linkend="gin-fast-update"/> for details), the penalty is
less than when it is not. But for very large updates it may still be
best to drop and recreate the index.
GINではfastupdateが有効である場合、このペナルティはそうでない場合よりも少なくなります。
（70.4.1を参照してください。）
しかし非常に大規模な更新では、インデックスの削除と再作成がまだ最善かもしれません。
Build time for a <acronym>GIN</acronym> index is very sensitive to
the <varname>maintenance_work_mem</varname> setting; it doesn't pay to
skimp on work memory during index creation.
GINインデックスの構築時間はmaintenance_work_memの設定に非常に敏感です。
インデックス作成時に作業メモリをより少なく使用しようとはしません。
During a series of insertions into an existing <acronym>GIN</acronym>
index that has <literal>fastupdate</literal> enabled, the system will clean up
the pending-entry list whenever the list grows larger than
<varname>gin_pending_list_limit</varname>. To avoid fluctuations in observed
response time, it's desirable to have pending-list cleanup occur in the
background (i.e., via autovacuum). Foreground cleanup operations
can be avoided by increasing <varname>gin_pending_list_limit</varname>
or making autovacuum more aggressive.
However, enlarging the threshold of the cleanup operation means that
if a foreground cleanup does occur, it will take even longer.
fastupdateが有効な既存のGINインデックスに対して挿入を繰り返す間、待機中の項目リストがgin_pending_list_limitより大きくなると、システムはこのリストを整理します。
観測される応答時間の変動を防ぐためには、待機中リストの整理をバックグラウンド（すなわち自動バキューム）で起きるようにすることが望まれます。
フォアグラウンドでの整理処理は、gin_pending_list_limitを大きくすること、もしくは自動バキュームをより積極的に行うことで防ぐことができます。
しかし、整理処理の閾値を大きくすることは、フォアグラウンドで整理処理が発生した時により長い時間がかかることを意味します。
<varname>gin_pending_list_limit</varname> can be overridden for individual
GIN indexes by changing storage parameters, which allows each
GIN index to have its own cleanup threshold.
For example, it's possible to increase the threshold only for the GIN
index which can be updated heavily, and decrease it otherwise.
gin_pending_list_limitは格納パラメータを変更することで個々のGINインデックスに対して上書きでき、それにより各GINインデックスが自身の整理閾値を持てます。
例えば、頻繁に更新される可能性のあるGINインデックスの閾値のみを増やして、それ以外は減らすことができます。
The primary goal of developing <acronym>GIN</acronym> indexes was to create support for highly scalable full-text search in <productname>PostgreSQL</productname>, and there are often situations when a full-text search returns a very large set of results. Moreover, this often happens when the query contains very frequent words, so that the large result set is not even useful. Since reading many tuples from the disk and sorting them could take a lot of time, this is unacceptable for production. (Note that the index search itself is very fast.) GINインデックス開発の主な目的は、スケーラビリティが高い全文検索のサポートをPostgreSQLで作成することでした。 全文検索の結果は非常に大規模な結果セットを返します。 さらに、問い合わせが非常に高頻度な単語を持つ場合、こうした状況はよく発生しますが、大規模な結果セットは有用ですらありません。 ディスクから大量のタプルを読み、ソートすることは長い時間がかかりますので、実運用レベルでは受け入れられません。 （インデックス検索自体は非常に高速であることに注意してください。）
To facilitate controlled execution of such queries,
<acronym>GIN</acronym> has a configurable soft upper limit on the
number of rows returned: the
<varname>gin_fuzzy_search_limit</varname> configuration parameter.
It is set to 0 (meaning no limit) by default.
If a non-zero limit is set, then the returned set is a subset of
the whole result set, chosen at random.
こうした問い合わせの実行を簡単に制御できるように、GINは返される行数に対して設定可能なソフト上限、gin_fuzzy_search_limit設定パラメータを持ちます。
これはデフォルトでは0です（無制限を意味します）。
非0の制限が設定された場合、返されるセットは結果セット全体からランダムに選んだサブセットになります。
<quote>Soft</quote> means that the actual number of returned results could differ somewhat from the specified limit, depending on the query and the quality of the system's random number generator. 「ソフト」は、問い合わせとシステムの乱数ジェネレータの品質に依存して、返される結果の実際の数が指定した上限より多少異なることを意味します。
From experience, values in the thousands (e.g., 5000 — 20000) work well. 経験上、数千（例えば5000から20000）の値がうまく動作します。