2つのテーブルを含む3つの内部ジョインを持つSELECTステートメントがあります。 ON句とWHERE句で参照される列に索引を作成するだけでなく、問合せを再作成する場合と同様に、結合を最適化するために行うことができますか？あなたが二回my_tableから同じレコードを選択しているので3つのテーブルを含む内部ジョイン
SELECT
...
FROM
my_table AS t1
INNER JOIN
my_table AS t2
ON
t2.id = t1.id
INNER JOIN
other_table AS t3
ON
t2.id = t3.id
WHERE
...
あなたはおそらく、あなたの例では、エラーを持って、あなたは本当にだけで行うことができます：
SELECT
...
FROM
my_table AS t1
INNER JOIN
other_table AS t3
ON
t1.id = t3.id
WHERE
...
ので、あなたのコード例T1に常になりますt2。
ただし、ON t2.idX = t1.id;あなたの質問に答えるためには、あなたが持っているものよりもはるかに優れたパフォーマンスを得ることができません。インデックスを付けることもできますし、さらに進んで外部キーの関係として定義することもできます（これはパフォーマンスの面であまり効果がありません非索引と索引付け）
代わりにwhere句を制限して見るのが好きかもしれません。おそらくそれはあなたの索引付けが（そうでなくても）有益であるかもしれません。
INNER JOINSではなくWHERE EXISTS（3つのテーブルすべてからデータを選択する必要がない場合）を使用してクエリを書くことはできますが、パフォーマンスはほぼ同じになります（ネストされたクエリの内部にある場合を除く）それでもレコードを見つける必要があるからです。
PostgreSQLのconfig、VACUUM ANALIZEおよびすべての一般的な最適化を調整できます。
これでは不十分で、数日を過ごすことができる場合、postgresql wikiで説明されているように、マテリアライズドビューを作成するためのコードを書くことができます。
In PostgreSQLほとんどのチューニングは実際のクエリには反映されません。目的は、オプティマイザが宣言型問合せをどのように実行するのが最適かを把握し、プログラムから実行する方法を指定するのを助けることです。これは、クエリが最適化されない場合や、クエリが最適化されない場合や、そうでない場合があることを示すものではありませんが、多くのレコードを取得している場合を除き、あなたが必要とするよりも（私は時々起こると見ている）。
あなたが最適な統計情報を持っていることを確認するには、vacuum analysisを実行することです。次に、Explain分析を使用して、予想される照会のパフォーマンスを実際のものと比較します。その時点から、索引などを調べます。この照会には、照会レベルで最適化する必要があるものはありません。しかしwhere句で実際のフィルタを調べたり、Explain分析の実際の出力がない場合は、それを示唆することはあまりありません。
通常、クエリで指定するのではなく、より良いクエリプランを選択するためにdbを微調整します。これは通常PostgreSQLの方法です。コメントには、例外があることに気付くことによって、もちろん認定されます。