Apakah itu ide / pendekatan yang baik untuk mengindeks kolom VARCHAR?

Kami menggunakan PostgreSQL v8.2.3.

Ada tabel yang terlibat: EMPLOYEE dan EMAILLIST .

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

2 tabel digabungkan sedemikian rupa sehingga jika EMPLOYEE.EMAIL1 atau EMPLOYEE.EMAIL2 tidak memiliki entri yang cocok, baris-baris itu akan dikembalikan.

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

Kolom EMAILyang merupakan varchar (256) dari EMAILLISTtabel diindeks. Sekarang, waktu respons adalah 14 detik.

Statistik jumlah tabel: Saat ini, EMPLOYEE telah mendapatkan 165.018 catatan & EMAILLIST telah mendapatkan 1.810.228 catatan, dan kedua tabel diharapkan akan tumbuh di masa mendatang.

1. Apakah itu ide / pendekatan yang baik untuk mengindeks kolom VARCHAR? Pertanyaan ini segera muncul di benak saya karena alasan kami belum mengindeks kolom VARCHAR sebelumnya di aplikasi kami. Saran / saran ahli tentang hal ini sangat dihargai.
2. Dengan kueri dan indeks saat ini, waktu respons 14 detik masuk akal atau apakah ada ruang untuk penyetelan lebih lanjut? Apa pengalaman / pendapat real-time pengguna lain berdasarkan pada ukuran tabel dan waktu respons seperti ini?

CATATAN: Persyaratan / kasus penggunaan aktual saya dijelaskan secara rinci di sini .

Tidak ada yang salah dengan mengindeks kolom varchar jika Anda akan melakukan kueri berdasarkan itu. Namun harap diingat bahwa ada batasan untuk beberapa indeks dan seberapa banyak mereka dapat diindeks dalam satu bidang. Misalnya Anda tidak dapat mengindeks kolom yang dapat berisi teks dalam jumlah tidak terbatas. Namun Anda harus dapat melakukan indeks pada varchar (256) tanpa masalah. Cobalah, dan analisis peningkatan kinerja kueri Anda untuk melihat apakah itu membantu.

Tidak ada masalah pengindeksan kolom varchar seperti itu

Di mana itu bisa menjadi masalah adalah ketika Anda memiliki kolom varchar sebagai FK di tabel miliar baris. Anda kemudian akan memiliki kunci pengganti untuk PK dan FK, tetapi Anda masih membutuhkan batasan / indeks unik pada kunci varchar alami.

Tabel Anda cukup kecil dan kinerjanya bisa terkait dengan klausa OR. Sayangnya, masalah yang sama berlaku tidak peduli bagaimana Anda menyusun kueri (dan saya tidak cukup akrab dengan PostgresSQL untuk menawarkan banyak maaf)

Coba singkirkan bagian "ATAU e2.email IS NULL" dari kueri Anda dan lihat seberapa cepat ia berjalan. Jika berjalan lebih cepat, Anda mungkin bisa menjalankannya lebih cepat dengan "gabungan semua"