by GitHub Actions [skip ci]

Author: actions-user

current/html/app-pgdump.html

@@ -91,30 +91,19 @@
    others, you'd probably settle for creating just the two indexes that
    best match the common types.
 </span>
-《マッチ度[81.438999]》もっとも単純なアプリケーション以外のほとんどすべてのアプリケーションでは、インデックスの有用な組み合わせはいろいろあります。
+もっとも単純なアプリケーション以外のほとんどすべてのアプリケーションでは、インデックスの有用な組み合わせはいろいろあります。
 このため、データベース開発者は妥協点を探してどのようなインデックスを提供するかを決定しなければなりません。
 複数列インデックスが最善な場合がありますし、別々のインデックスを作成し、インデックスの組み合わせ機能に依存する方が優れている場合もあります。
 例えば、作業に<code class="literal">x</code>列のみを含む場合と<code class="literal">y</code>列のみを含む場合、両方の列を含む場合が混在する問い合わせが含まれる場合、<code class="literal">x</code>と<code class="literal">y</code>に対し、別個に2つのインデックスを作成し、両方の列を使用する問い合わせを処理する時にインデックスの組み合わせに依存することを選ぶことができます。
 また、<code class="literal">(x, y)</code>に対する複数列インデックスを作成することもできます。
 両方の列を含む問い合わせでは、通常このインデックスの方がインデックスの組み合わせよりも効率的です。
-しかし、<a class="xref" href="indexes-multicolumn.html" title="11.3. 複数列インデックス">11.3</a>で説明した通り、<code class="literal">y</code>のみを含む問い合わせではほとんど意味がありません。
-従って、このインデックスのみとすることはできません。
-複数列インデックスと<code class="literal">y</code>に対する別のインデックスの組み合わせがかなりよく役に立ちます。
+しかし、<a class="xref" href="indexes-multicolumn.html" title="11.3. 複数列インデックス">11.3</a>で説明した通り、<code class="literal">y</code>のみを含む問い合わせはあまり有用ではありません。
+どの程度有用かどうかは、B-treeインデックスのスキップスキャン最適化がどれほど効果的か次第です。
+<code class="literal">x</code>の個別値が数百個以下である場合、スキップスキャンは<code class="literal">y</code>の値をかなり効率的に検索するでしょう。
+<code class="literal">(x, y)</code>に対する複数列インデックスと<code class="literal">y</code>に対する別のインデックスの組み合わせもかなりよく役に立ちます。
 <code class="literal">x</code>のみを含む問い合わせでは、複数列インデックスを使用することができます。
-しかし、これはより大きくなりますので、<code class="literal">x</code> のみインデックスよりも低速になります。
+しかし、これはより大きくなりますので、<code class="literal">x</code>のみのインデックスよりも低速になります。
 最後の別方法は、3つのインデックスすべてを作成することです。
 しかしこれはおそらく、テーブルの検索頻度が更新頻度よりもかなり高く、3種類の問い合わせすべてが良く使用される場合のみ合理的です。
 問い合わせの中の1つの頻度が他よりも少なければ、おそらく良く使用される種類にもっとも合うように2つだけインデックスを作成した方がよいでしょう。
-《機械翻訳》最も単純なアプリケーションを除くほとんどのアプリケーションでは、有用なインデックスのさまざまな組み合わせがあり、データベースの開発者はどのインデックスを提供するかを決定するためにmakeのトレードオフを行う必要があります。
-複数列のインデックスがベストである場合もありますが、個別のインデックスを作成してインデックスの組み合わせの機能に依存する方がよい場合もあります。
-例では、カラムのみ<code class="literal">x</code>カラムのみ<code class="literal">y</code>両方の列を含む場合もあるを含む問い合わせが混在しているワークロードの場合、<code class="literal">x</code>と<code class="literal">y</code>の両方の列を含む場合もあるに対して2つの個別のインデックスを作成することを選択できます。
-<code class="literal">(x, y)</code>の両方の列を含む問い合わせをプロセスするためにインデックスの組み合わせに依存します。
-に複数列インデックスを作成することもできます。
-このインデックスは通常、両方の列を含む問い合わせに対してインデックスの組み合わせよりも効率的ですが、<a class="xref" href="indexes-multicolumn.html" title="11.3. 複数列インデックス">11.3</a>で説明したように、<code class="literal">y</code>のみを含む問い合わせに対してはあまり有用ではありません。
-どの程度有用であるかは、B-ツリーインデックススキップスキャン最適化がどれだけ効果的であるかに依存します。
-<code class="literal">x</code>が数百を超える異なる値を持たない場合、スキップスキャンは合理的に効率的に特定の<code class="literal">y</code>値実行の値を検索します。
-<code class="literal">(x, y)</code>のインデックスと<code class="literal">y</code>の個別のの組み合わせも合理的によく機能します。
-<code class="literal">x</code>のみを含む問い合わせに対しては、のを使用できますが、これは<code class="literal">x</code>単独のよりも大きく、したがって低速になります。
-最後の選択肢は3つのインデックスすべてを作成することですが、これはおそらく、更新されるよりもはるかに頻繁に検索され、の3つのタイプすべてが一般的である場合にのみ合理的です。
-マッチ複数列問い合わせインデックステーブルベストmakeインデックスインデックス問い合わせ複数列
   </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="indexes-ordering.html" title="11.4. インデックスとORDER BY">前へ</a> </td><td width="20%" align="center"><a accesskey="u" href="indexes.html" title="第11章 インデックス">上へ</a></td><td width="40%" align="right"> <a accesskey="n" href="indexes-unique.html" title="11.6. 一意インデックス">次へ</a></td></tr><tr><td width="40%" align="left" valign="top">11.4. インデックスと<code class="literal">ORDER BY</code> </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0文書">ホーム</a></td><td width="40%" align="right" valign="top"> 11.6. 一意インデックス</td></tr></table></div></body></html>

current/html/indexes-bitmap-scans.html

@@ -71,24 +71,12 @@
    the generated constraint can be used in conjunction with a later column
    constraint from the query predicate).
 </span>
-《マッチ度[52.363636]》複数列に対するB-treeインデックスをインデックス対象列の任意の部分集合を含む問い合わせ条件で使用することができます。
-しかし、先頭側の（左側）列に制約がある場合に、このインデックスはもっとも効率的になります。
-正確な規則は、先頭側の列への等価制約、および、等価制約を持たない先頭列への不等号制約がスキャン対象のインデックス範囲を制限するために使用されます。
-これらの列の右側の列に対する制約は、このインデックス内から検査されます。
-ですので、テーブルアクセスを適切に抑えますが、スキャンされるインデックスの範囲を減らしません。
-例えば、<code class="literal">(a, b, c)</code>に対するインデックスがあり、<code class="literal">WHERE a = 5 AND b &gt;= 42 AND c &lt; 77</code>という問い合わせ条件があったとすると、
-<code class="literal">a</code> = 5かつ<code class="literal">b</code> = 42を持つ項目を先頭に、<code class="literal">a</code> = 5となる最後の項目までのインデックスをスキャンしなければなりません。
-<code class="literal">c</code> &gt;= 77を持つインデックス項目は飛ばされますが、スキャンを行わなければなりません。
-このインデックスは原理上、 <code class="literal">a</code>に対する制約を持たず、<code class="literal">b</code>あるいは<code class="literal">c</code>に制約に持つ問い合わせでも使用することができます。
-しかし、インデックス全体がスキャンされますので、ほとんどの場合、プランナはインデックスの使用よりもシーケンシャルテーブルスキャンを選択します。
-《機械翻訳》複数列B-ツリーインデックスは、問い合わせの列の任意のサブセットを含むインデックス条件で使用できますが、インデックスは先頭（左端）の列に制約がある場合に最も効率的です。
-正確なルールは、先頭の列に対する等式制約、つまり等式制約を持たない最初のカラムに対するプラスの不等式制約が、スキャンされるインデックスの部分を制限するために常に使用されるということです。
-これらの列の右側の列に対する制約はインデックスでチェックされるため、常にテーブルへの訪問を適切に保存しますが、スキャンする必要のあるインデックスの部分を必ずしも減らすとは限りません。
-B-ツリーインデックススキャンがスキップスキャン最適化を効果的に適用できる場合は、インデックス検索を繰り返してインデックスをナビゲートするときに、すべてのカラム制約を適用します。
-これにより、1つまたは複数の列（インデックスからの最下位のの前）に従来の等式がない場合でも、読み取られるインデックスの部分を減らすことができます。
-は、内部的に動的等式を生成することによって機能します。
-これは、内のすべての可能な値に一致します（ただし、に由来する等式を持たないが与えられた場合にのみ、生成されたが単位からの後の割引とともにで使用できる場合にのみ）。
-インデックスカラムスキップ制約問い合わせ述語制約問い合わせ制約問い合わせ制約スキャンカラム制約カラム論理積述語述語カラム
+複数列に対するB-treeインデックスは、インデックス対象列の任意の部分集合を含む問い合わせ条件で使用できますが、もっともインデックスの効率が良いのは、先頭（左側）の列に制約がある場合です。
+正確な規則は、先頭の列に対する等価制約、および等価制約を持たない先頭の列に対する不等式制約は、常にスキャン対象のインデックス範囲を制限するために使用されるということです。
+これらの列の右側の列に対する制約はインデックスで検査されるため、常にテーブルへのアクセスを適切に抑えますが、必ずしもスキャンしなければならないインデックスの範囲を減らすわけではありません。
+B-treeインデックススキャンでスキップスキャン最適化を効果的に適用できる場合は、インデックス検索を繰り返してインデックスを辿るときに、すべての列制約が適用されます。
+これにより、（問い合わせの述語に含まれるもっとも重要度の低いインデックス列より前に位置する）1つまたは複数の列に従来の等価制約がない場合でも、読まなければならないインデックスの範囲を減らすことができます。
+スキップスキャンは、インデックス列において取り得るすべての値と一致する動的な等価制約を内部的に生成することで機能しています（ただし、問い合わせの述語に含まれる等価制約のない列に対してのみ適用され、かつ生成された制約が問い合わせの述語に含まれる後続の列制約と組み合わせて使用できる場合に限ります）。
   </p><p>
 <span class="original">
    For example, given an index on &lt;literal&gt;(x, y)&lt;/literal&gt;, and a query
@@ -105,10 +93,10 @@
    then the entire index will have to be scanned, so in most cases the planner
    will prefer a sequential table scan over using the index.
 </span>
-《機械翻訳》例では、インデックスon <code class="literal">(x, y)</code>、および問い合わせ条件<code class="literal">WHERE y = 7700</code>、B-ツリーインデックススキャンはスキップスキャン最適化を適用できる場合があります。
-これは一般に、問い合わせプランナが、テーブルで利用可能なインデックスが与えられた場合、反復<code class="literal">WHERE x = N AND y = 7700</code>可能性のあるすべての値<code class="literal">N</code>または実際にインデックスに格納されているすべて<code class="literal">x</code>の値の検索が可能な最速のアプローチであると想定している場合に発生します。
-このアプローチは一般に、明確な<code class="literal">x</code>値が非常に少ないため、プランナがインデックスの大部分に対してスキャンからスキップを想定している場合にのみ使用されます（リーフページの大部分には関連するタプルが含まれていない可能性があるため）。
-明確な<code class="literal">x</code>値が多数ある場合は、インデックス全体をスキャンする必要があるため、ほとんどの場合、プランナはインデックスよりシーケンシャルテーブルスキャンを優先します。
+たとえば、<code class="literal">(x, y)</code>に対するインデックスと問い合わせ条件<code class="literal">WHERE y = 7700</code>では、B-treeインデックススキャンでスキップスキャン最適化を適用できる場合があります。
+これは通常、問い合わせプランナがそのテーブルで使用可能なインデックスを考慮した時に、<code class="literal">WHERE x = N AND y = 7700</code>の検索を、<code class="literal">N</code>で取り得るすべての値（または実際にインデックスに格納されているすべての<code class="literal">x</code>の値）に対して繰り返す方法が最速であると想定している場合に発生します。
+この方法は通常、<code class="literal">x</code>の個別値が非常に少なく、ほとんどのインデックスをスキップしてスキャンする（ほとんどのリーフページには関連するタプルが含まれないため）とプランナが期待する場合にのみ採用されます。
+<code class="literal">x</code>の個別値が多い場合、インデックス全体のスキャンが必要になる状況になりうるため、ほとんどの場合プランナはインデックスを使用するよりもシーケンシャルスキャンを好みます。
   </p><p>
 <span class="original">
    The skip scan optimization can also be applied selectively, during B-tree
@@ -128,11 +116,10 @@
    index where the first tuple &lt;literal&gt;a = 5 AND b = N + 1&lt;/literal&gt;
    appears).
 </span>
-《機械翻訳》スキップスキャン最適化は、問い合わせツリーからの少なくともいくつかの有用な制約を有するB-述語スキャン中に選択的に適用することもできる。
-例の場合、インデックスon <code class="literal">(a, b, c)</code>および問い合わせ条件が指定されている場合、インデックスは<code class="literal">a</code>=5および<code class="literal">b</code>=42の最初のエントリから<code class="literal">a</code>=5の最後のエントリまでスキャンする必要がある場合があります。
-<code class="literal">c</code>&gt;=77のインデックスエントリはテーブルレベルでフィルタする必要はありませんが、インデックス内でスキップに利益をもたらす場合とそうでない場合があります。
-スキップが行われると、スキャンは新しいインデックス検索を開始して、現在<code class="literal">a</code>=5および<code class="literal">b</code>=Nグループ化の末尾（つまり、最初のタプル<code class="literal">a = 5 AND b = N AND c &gt;= 77</code>が表示されるインデックス内の位置）から、次のそのような（つまり、最初の<code class="literal">a = 5 AND b = N + 1</code>が表示される内の位置）に自分自身を再配置します。
-タプルグループ化スタートインデックス<code class="literal">WHERE a = 5 AND b &gt;= 42 AND c &lt; 77</code>
+スキップスキャンの最適化は、問い合わせの述語に有用な制約が少なくともいくつかあるB-treeスキャン中に、選択的に適用することもできます。
+たとえば、<code class="literal">(a, b, c)</code>にインデックスがあり、<code class="literal">WHERE a = 5 AND b &gt;= 42 AND c &lt; 77</code>という問い合わせ条件がある場合、インデックスは<code class="literal">a</code> = 5および<code class="literal">b</code> = 42の最初のエントリから<code class="literal">a</code> = 5の最後のエントリまでスキャンする必要があるかもしれません。
+<code class="literal">c</code> &gt;= 77のインデックスエントリはテーブルレベルでフィルタリングする必要はありませんが、インデックス内でスキップすると効果がある場合とない場合があります。
+スキップが行われると、スキャンは新しいインデックス検索を開始し、現在の<code class="literal">a</code> = 5と<code class="literal">b</code> = Nのグループの末尾（つまり、<code class="literal">a = 5 AND b = N AND c &gt;= 77</code>の最初のタプルが現れるインデックスの位置）から、次のグルーピングの開始位置（つまり、<code class="literal">a = 5 AND b = N + 1</code>の最初のタプルが現れるインデックスの位置）まで位置を変更します。
   </p><p>
 <span class="original">
    A multicolumn GiST index can be used with query conditions that