# Kurator Customers 搜尋

## 數據
https://docs.google.com/spreadsheets/d/1ekMoE8DEugwkH-U6xCtAg3J5Yjm4EX8eFLnZ9IljaYY/edit#gid=274134963

## 結論

建議使用 project_id index 搭配 ILIKE 或 lower LIKE，移除 trgm 或 bigm 直到大型專案的客戶有反應為止。

- project_id 的 index 對大部分的粉專有效
- trgm 或 bigm 只對超大型粉專有幫助
- 當搜尋的內容是英文 3 個字時：trgm 有效
- 當搜尋的內容是中文 1～2 個字時：bigm 有效
- 需要實測在 server 上的數據

## 觀察到的細節

- 比較 ILIKE 與 lower LIKE 神奇的發現：
- where lower LIKE 的效能跟 where ILIKE 差不多
- 但 where project_id and lower LIKE 的效能比 where project_id and ILIKE 好很多

- project_id 的 index
- 在 1 萬人的粉專表現非常理想
- 在 80 萬人的粉專表現不佳
- 隨著客戶數增加，可以預想 project_id index 的重要性也會隨之增加，因為 customers 的數量增加時，80萬人粉專佔總 customers 人數相對下降，index 的作用就顯現。

- 加完 index 後必須執行 ANALYZE 才能確保抓到的數據正確
- 重現的步驟
1. create index bigm_lower
2. where lower LIKE ‘lax’ offest 100 limit : 500ms
3. explain: Seq Scan
4. ANALYZE customers
5. where lower LIKE ‘lax’ offest 100 limit: 22ms
6. explain: Bitmap Index Scan

- 多重 index 組合
- 發動的時候效能也沒有比較好的感覺
- 應是資料分布所造成，資料量更大的情況下或許會有幫助

- 新電腦所需的耗時是舊電腦的一半，在我的新電腦上：
- project_id and LIKE 無 index： 600 ms
- project_id and ILIKE 無 index：2000 ms
- project_id and lower LIKE 無 index： 500 ms (why)
- project_id and LIKE project_id index： 500 ms
- project_id and ILIKE project_id index： 700 ms
- project_id and lower LIKE project_id index： 500 ms