VARCHARカラムにインデックスを付けるのは良いアイデア/アプローチですか？

PostgreSQL v8.2.3を使用しています。

関係するテーブルがあります：EMPLOYEEとEMAILLIST。

Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)

2つのテーブルは、EMPLOYEE.EMAIL1またはEMPLOYEE.EMAIL2に一致するエントリがない場合、それらの行が返されるように結合されます。

SELECT employee.email1, employee.email2,
        e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched
   FROM employee
   LEFT JOIN emaillist e1 ON e1.email = employee.email1
   LEFT JOIN emaillist e2 ON e2.email = employee.email2
 WHERE e1.email IS NULL OR e2.email IS NULL

テーブルのvarchar（256）である列EMAILにインデックスが付けられます。現在、応答時間は14秒です。EMAILLIST

テーブル数の統計：現在、EMPLOYEEには165,018レコード、EMAILLISTには1,810,228レコードがあり、両方のテーブルは将来的に増加する予定です。

1. VARCHARカラムにインデックスを付けるのは良いアイデア/アプローチですか？この質問は、アプリケーションで以前にVARCHAR列のインデックスを作成したことがないため、すぐに思いつきます。これに関する専門家のアドバイス/提案は高く評価されています。
2. この現在のクエリとインデックスでは、14秒の応答時間は妥当ですか、またはさらに調整する余地はありますか？この種のテーブルサイズと応答時間に基づく他のユーザーのリアルタイムエクスペリエンス/意見は何ですか？

注：私の実際の要件/ユースケースは、ここで詳細に説明されています。

varchar列に基づいてクエリを実行する場合、varchar列のインデックス付けに問題はありません。ただし、一部のインデックスには制限があり、単一のフィールドでインデックスを作成できる量に制限があることに注意してください。たとえば、無制限の量のテキストを含むことができる列にインデックスを付けることはできません。ただし、varchar（256）のインデックスを問題なく実行できるはずです。それを試して、クエリのパフォーマンスの改善を分析し、それが役立つかどうかを確認してください。

varcharカラムのインデックス作成の問題はありません

問題になる可能性があるのは、varchar列が10億行のテーブルのFKである場合です。その後、PKおよびFKの代理キーがありますが、自然なvarcharキーには一意の制約/インデックスが必要です。

テーブルは非常に小さく、パフォーマンスはOR句に関連している可能性があります。残念ながら、クエリをどのように構成しても同じ問題が当てはまります（そして、残念ながらPostgresSQLについて十分な知識がありません）

クエリの「OR e2.email IS NULL」部分を取り除き、実行速度を確認してください。より高速に実行される場合は、「すべてを結合」することでより高速に実行できる場合があります