ਹਕੀਕਤ ਵਿੱਚ “ਕਾਫ਼ੀ ਖੋਜ” ਕਿਵੇਂ ਲੱਗਦੀ ਹੈ\n\nਜ਼ਿਆਦਾਤਰ ਲੋਕ "ਫੁੱਲ-ਟੈਕਸਟ ਖੋਜ" ਨਹੀਂ ਮੰਗਦੇ। ਉਹ ਇੱਕ ਐਸਾ search box ਮੰਗਦੇ ਹਨ ਜੋ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੋਵੇ ਅਤੇ ਪਹਿਲੇ ਪੰਨੇ 'ਤੇ ਉਹੀ ਚੀਜ਼ ਮਿਲ ਜਾਵੇ ਜੋ ਉਹ ਸੋਚ ਰਹੇ ਸਨ। ਜੇ ਨਤੀਜੇ ਧੀਮੇ, ਔਟ-ਆਫ-ਆਰਡਰ, ਜਾਂ ਸ਼ੋਰ ਵਾਲੇ ਹਨ, ਯੂਜ਼ਰ ਨੂੰ ਨਹੀਂ ਪਰवाह ਕਿ ਤੁਸੀਂ PostgreSQL FTS ਵਰਤਿਆ ਜਾਂ ਕੋਈ ਵੱਖਰਾ ਇੰਜਣ। ਉਹ ਸਿਰਫ਼ ਖੋਜ 'ਤੇ ਭਰੋਸਾ ਘਟਾ ਦਿੰਦੇ ਹਨ।\n\nਇਹ ਇੱਕ ਫੈਸਲਾ ਹੈ: ਖੋਜ ਨੂੰ Postgres ਦੇ ਅੰਦਰ ਰੱਖਣਾ ਜਾਂ ਇੱਕ ਸਮਰਪਿਤ search engine ਜੋੜਨਾ। ਟਾਰਗੇਟ ਪਰਫੈਕਟ relevance ਨਹੀਂ ਹੁੰਦਾ। ਟਾਰਗੇਟ ਇੱਕ ਮਜ਼ਬੂਤ ਬੇਸਲਾਈਨ ਹੈ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ship ਹੋ ਜਾਵੇ, ਚਲਾਉਣ ਵਿੱਚ ਆਸਾਨ ਹੋਵੇ, ਅਤੇ ਤੁਹਾਡੇ ਐਪ ਦੀ ਅਸਲ ਵਰਤੋਂ ਲਈ ਕਾਫ਼ੀ ਹੋਵੇ।\n\nਕਈ ਐਪਾਂ ਲਈ, PostgreSQL ਫੁੱਲ-ਟੈਕਸਟ ਖੋਜ ਲੰਬੇ ਸਮੇਂ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਟੈਕਸਟ ਫੀਲਡ ਹਨ (title, description, notes), ਬੇਸਿਕ ranking, ਅਤੇ ਇੱਕ-ਦੋ ਫਿਲਟਰ (status, category, tenant), ਤਾਂ Postgres ਬਿਨਾਂ ਵਾਧੂ ਇੰਫਰਾਸਟਰਕਚਰ ਦੇ ਇਹ ਸਭ ਹینڈਲ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਘੱਟ ਮੂਵਿੰਗ ਪਾਰਟਸ, ਸਧਾਰਣ backups, ਅਤੇ ਘੱਟ "ਖੋਜ ਡਾਊਨ ਪਰ ਐਪ ਚਲ ਰਹੀ" ਵਰਗੀਆਂ ਘਟਨਾਵਾਂ ਮਿਲਦੀਆਂ ਹਨ।\n\n"ਕਾਫ਼ੀ" ਆਮਤੌਰ 'ਤੇ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਇਕੱਠੇ ਤਿੰਨ ਟਾਰਗੇਟ ਹਾਸਲ ਕਰ ਸਕੋ:\n\n- ਕੁਆਲਿਟੀ: ਆਮ ਕੁਐਰੀਆਂ ਲਈ ਸਹੀ ਆਈਟਮ ਸਿਖਰ ਤੇ ਨੇੜੇ ਆਉਂਦੇ ਹਨ ਅਤੇ obvious matches ਗੁੰਮ ਨਹੀਂ ਹੁੰਦੀਆਂ।\n- ਸਪੀਡ: ਨਤੀਜੇ ਨਾਰਮਲ ਲੋਡ ਹੇਠ ਤੇਜ਼ ਆਉਂਦੇ ਹਨ (ਸਿਰਫ਼ ਤੁਹਾਡੇ ਲੈਪਟਾਪ 'ਤੇ ਨਹੀਂ)।\n- ਪਰੇਸ਼ਨਲ ਕੋਸ਼ਿਸ਼: ਤੁਹਾਡੀ ਟੀਮ ਇਸਨੂੰ ਦੂਜੇ ਕਲੱਸਟਰ, ਵਾਧੂ ਮਾਨੀਟਰਨਿੰਗ, ਜਾਂ ਵੱਖਰੇ ਇੰਡੈਕਸਿੰਗ ਪਾਈਪਲਾਈਨ ਤੋਂ ਬਿਨਾਂ ਸੰਭਾਲ ਸਕਦੀ ਹੈ।\n\nਇੱਕ Konkreet ਉਦਾਹਰਨ: ਇੱਕ SaaS ਡੈਸ਼ਬੋਰਡ ਜਿੱਥੇ ਯੂਜ਼ਰ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਨਾਮ ਅਤੇ ਨੋਟਸ ਨਾਲ ਖੋਜਦੇ ਹਨ। ਜੇ "onboarding checklist" ਵਰਗੀ query ਸਹੀ ਪ੍ਰੋਜੈਕਟ top 5 ਵਿੱਚ, ਇੱਕ ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਲਿਆਉਂਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਨਿਰੰਤਰ analyzers ਤ੍ਯੂਨ ਜਾਂ reindexing ਨਹੀਂ ਕਰ ਰਹੇ, ਤਾਂ ਇਹ "ਕਾਫ਼ੀ" ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇਹਨਾਂ ਟਾਰਗੇਟਾਂ ਨੂੰ ਮਿਲਾਉਣ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਟਿਲਤਾ ਜੋੜਨੀ ਪੈਂਦੀ ਹੈ, ਤਦ "built-in search vs search engine" ਇੱਕ ਅਸਲੀ ਸੁਆਲ ਬਣ ਜਾਂਦਾ ਹੈ।\n\n## ਆਮ ਖੋਜ ਲੋੜਾਂ ਅਤੇ ਉਹ ਕੀ ਦਰਸਾਉਂਦੀਆਂ ਹਨ\n\nਟੀਮਾਂ ਅਕਸਰ ਖੋਜ ਨੂੰ ਫੀਚਰਾਂ ਵਿੱਚ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਨਤੀਜਿਆਂ ਵਿੱਚ। ਲਾਭਦਾਇਕ ਕਦਮ ਇਹ ਹੈ ਕਿ ਹਰ ਫੀਚਰ ਨੂੰ ਇਹ ਵਿੱਚ ਤਰਜਮਾ ਕਰੋ ਕਿ ਉਸਨੂੰ ਬਣਾਉਣ, ਟਿਊਨ ਕਰਨ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਰੱਖਣ ਦੀ ਕੀ ਲਾਗਤ ਹੋਏਗੀ।\n\nਸ਼ੁਰੂਆਤੀ ਬੇਨਤੀਆਂ ਆਮਤੌਰ 'ਤੇ ਇਹਾਂ ਵਰਗੀ ਲੱਗਦੀਆਂ ਹਨ: typo tolerance, facets ਅਤੇ filters, highlights, “smart” ranking, ਅਤੇ autocomplete। ਪਹਿਲੀ ਵਰਜਨ ਲਈ, ਮਸਟ-ਹੈਵਜ਼ ਨੂੰ nice-to-haves ਤੋਂ ਵੱਖਰਾ ਕਰੋ। ਇੱਕ ਬੇਸਿਕ search box ਨੂੰ ਆਮਤੌਰ 'ਤੇ ਸਿਰਫ਼ relevant ਆਈਟਮ ਲੱਭਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਆਮ ਸ਼ਬਦਾਂ ਦੇ ਰੂਪਾਂ (plural, tense) ਨੂੰ ਹੇਠਾਂ ਲਿਆਉਣਾ, ਸਧਾਰਣ ਫਿਲਟਰਾਂ ਦਾ ਆਦਰ ਕਰਨਾ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਟੇਬਲ ਵਧਾਉ, ਤੇਜ਼ ਰਹਿਣਾ। ਇਸੀ ਥਾਂ Postgres ਆਮਤੌਰ 'ਤੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ।\n\nPostgres ਵਧੀਆ ਹੈ ਜਦੋਂ ਤੁਹਾਡੀ ਸਮੱਗਰੀ ਆਮ ਟੈਕਸਟ ਫੀਲਡਾਂ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਖੋਜ ਨੂੰ ਡੇਟਾ ਦੇ ਨੇੜੇ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ: help articles, blog posts, support tickets, internal docs, product titles and descriptions, ਜਾਂ customer records 'ਤੇ ਨੋਟਸ। ਇਹ ਜ਼ਿਆਦਾਤਰ "ਮੈਨੂੰ ਸਹੀ ਰਿਕਾਰਡ ਲੱਭਕੇ ਦਿਖਾਓ" ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਨਾ ਕਿ "ਇੱਕ search ਉਤਪਾਦ ਬਣਾਓ" ਦੀਆਂ।\n\nNice-to-haves ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ ਜਟਿਲਤਾ ਆਹਿਸਤਾਂ ਘੁਸਦੀ ਹੈ। typo tolerance ਅਤੇ ਰਿਚ autocomplete ਆਮਤੌਰ 'ਤੇ ਵਾਧੂ ਟੂਲਿੰਗ ਵੱਲ ਧਕੇਲ ਦਿੰਦੇ ਹਨ। Facets Postgres ਵਿੱਚ ਸੰਭਵ ਹਨ, ਪਰ ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ facets, ਡੀਪ analytics, ਅਤੇ ਬੜੇ ਡੈਟਾਸੈਟਾਂ ਵਿੱਚ ਤੁਰੰਤ counts ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਮਰਪਿਤ ਇੰਜਣ ਲਾਭਦਾਇਕ ਲੱਗਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ।\n\nਛੁਪੇ ਹੋਏ ਖ਼ਰਚ ਅਕਸਰ ਲਾਇਸੈਂਸ ਫੀ ਤੋਂ ਘੱਟ ਹੁੰਦੇ ਹਨ। ਇਹ ਦੂਜੇ ਸਿਸਟਮ ਦਾ ਹੋਣਾ ਹੈ। ਇਕ ਵਾਰੀ ਤੁਸੀਂ ਖੋਜ ਇੰਜਣ ਜੋੜ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ data syncing ਅਤੇ backfills (ਅਤੇ ਉਹਨਾਂ ਦੇ bugs), ਮਾਨੀਟਰਨਿੰਗ ਅਤੇ ਅਪਗਰੇਡਸ, "ਖੋਜ ਕਿਉਂ ਪੁਰਾਣਾ ਡਾਟਾ ਦਿਖਾ ਰਿਹਾ ਹੈ?" ਵਾਲਾ support ਕੰਮ, ਅਤੇ relevance ਦੇ ਦੋ ਸੈਟ ਨਾਬਸ ਸ਼ਾਮਲ ਕਰ ਲੈਂਦੇ ਹੋ।\n\nਜੇ ਤੁਸੀਂ unsure ਹੋ, ਤਾਂ Postgres ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਕੁਝ ਸਧਾਰਣ ship ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਤਦ ਹੀ ਦੂਜਾ ਇੰਜਣ ਜੋੜੋ ਜਦੋਂ ਕੋਈ ਸਪਸ਼ਟ ਲੋੜ ਪੂਰੀ ਨਾ ਹੋਵੇ।\n\n## ਇੱਕ ਸਧਾਰਣ ਫੈਸਲਾ ਨਿਯਮ: built-in search vs dedicated engine\n\nਇੱਕ ਤਿੰਨ-ਚੈੱਕ ਨਿਯਮ ਵਰਤੋ। ਜੇ ਤੁਸੀਂ ਸਾਰੇ ਤਿੰਨ ਪਾਸ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ PostgreSQL full-text search ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਬੁਰੇ ਤਰੀਕੇ ਨਾਲ fail ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਮਰਪਿਤ search engine ਬਾਰੇ ਸੋਚੋ।\n\n### ਤਿੰਨ ਚੈੱਕ\n\n1) Relevance needs: ਕੀ “ਕਾਫ਼ੀ-ਅੱਛਾ” ਨਤੀਜੇ ਕਬੂਲ ਹਨ, ਜਾਂ ਤੁਹਾਨੂੰ near-perfect ranking ਚਾਹੀਦੀ ਹੈ ਬਹੁਤ ਸਾਰੇ edge cases ਲਈ (typos, synonyms, “people also searched,” personalized results)? ਜੇ ਤੁਸੀਂ ਕਦੇ-ਕਦੇ imperfect ordering ਸਹਿ ਸਕਦੇ ਹੋ, ਤਾਂ Postgres ਆਮਤੌਰ 'ਤੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ।\n\n2) Query volume and latency: ਤੁਹਾਨੂੰ peak 'ਤੇ ਕਿੰਨੀ searches ਪ੍ਰਤੀ ਸਕਿੰਡ ਦੀ ਉਮੀਦ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਅਸਲੀ latency ਬਜਟ ਕੀ ਹੈ? ਜੇ search traffic ਛੋਟੀ ਹਿੱਸਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਠੀਕ ਇੰਡੈਕਸ ਨਾਲ queries ਨੂੰ ਤੇਜ਼ ਰੱਖ ਸਕਦੇ ਹੋ, ਤਾਂ Postgres ਠੀਕ ਹੈ। ਜੇ search ਇੱਕ ਵੱਡਾ workload ਬਣ ਜਾਏ ਅਤੇ core reads/writes ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਲੱਗੇ, ਤਾਂ ਇਹ ਚੇਤਾਵਨੀ ਹੈ।\n\n3) Complexity: ਕੀ ਤੁਸੀਂ ਇਕ-ਦੋ ਟੈਕਸਟ ਫੀਲਡਾਂ ਨੂੰ search ਕਰ ਰਹੇ ਹੋ, ਜਾਂ ਬਹੁਤ ਸਾਰੇ ਸਿਗਨਲ (tags, filters, time decay, popularity, permissions) ਅਤੇ ਬਹੁਭਾਸ਼ਾਈ ਸਮੱਗਰੀ ਜੋੜ ਰਹੇ ਹੋ? ਜਿੰਨੀ ਜ਼ਿਆਦਾ ਜਟਿਲ ਲੌਜਿਕ ਹੋਵੇਗੀ, SQL ਦੇ ਅੰਦਰ ਸੀਮਤੀਆਂ ਉਤਨੀ ਹੀ ਜ਼ਿਆਦਾ ਮਹਿਸੂਸ ਹੋਣਗੀਆਂ।\n\nਇੱਕ ਸੁਰੱਖਿਅਤ ਸ਼ੁਰੂਆਤ ਸਧਾਰਨ ਹੈ: Postgres ਵਿੱਚ ਇੱਕ ਬੇਸਲਾਈਨ ship ਕਰੋ, slow queries ਅਤੇ "no result" searches ਲੌਗ ਕਰੋ, ਅਤੇ ਤਦ ਨਿਰਣਾ ਕਰੋ। ਕਈ ਐਪ ਕਦੇ ਵੀ ਇਸਨੂੰ ਨਾਂਹੀਂ ਛੱਡਦੇ, ਅਤੇ ਤੁਸੀਂ ਦੂਜੇ ਸਿਸਟਮ ਨੂੰ ਜਲਦੀ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਬਚ ਜਾਂਦੇ ਹੋ।\n\nਲਾਲ ਝੰਡੇ ਜੋ ਆਮਤੌਰ 'ਤੇ ਸਮਰਪਿਤ ਇੰਜਣ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ:\n\n- ਤੁਹਾਨੂੰ ਉੱਚ ਗੁਣਵੱਤਾ typo tolerance, synonyms, ਜਾਂ autocomplete ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਚਾਹੀਦੀ ਹੈ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
What does “enough search” actually mean for a real app?
PostgreSQL full-text search "ਕਾਫ਼ੀ" ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕੋ ਸਮੇਂ ਇਹ ਤਿੰਨ ਚੀਜ਼ਾਂ ਹਾਸਲ ਕਰ ਸਕਦੇ ਹੋ:
- Relevant results: ਆਮ ਮੈਚੇਜ਼ ਸਿੱਖਰੇ ਤੇ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ।
- Fast responses: ਨਤੀਜੇ ਨਾਰਮਲ ਲੋਡ ਹੇਠ ਵੀ ਤੇਜ਼ ਰਹਿੰਦੇ ਹਨ।
- Low ops overhead: ਤੁਹਾਨੂੰ ਦੂਜੇ ਸਿਸਟਮ ਜਾਂ sync pipeline ਨਹੀਂ ਚਲਾਉਣੇ ਪੈਂਦੇ।
ਜੇ ਤੁਸੀਂ ਇਹ ਸਭ ਇੱਕ ਸਟੋਰ ਕੀਤੀ tsvector + GIN ਇੰਡੈਕਸ ਨਾਲ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਵਧੀਆ ਸਥਿਤੀ ਵਿੱਚ ਹੋ।
Should I start with Postgres search or add a search engine right away?
ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ PostgreSQL full-text search ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਹ ਤੇਜ਼ੀ ਨਾਲ ship ਹੁੰਦਾ ਹੈ, ਤੁਹਾਡੇ ਡੇਟਾ ਅਤੇ ਖੋਜ ਨੂੰ ਇੱਕ ਥਾਂ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਵੱਖਰਾ ਇੰਡੈਕਸਿੰਗ ਪਾਈਪਲਾਈਨ ਬਣਾਉਣ ਅਤੇ ਬਰਕਰਾਰ ਰੱਖਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ。
ਤੁਸੀਂ ਇੱਕ ਸਮਰੱਥ ਇੰਜਣ ਤਦ ਹੀ ਜੋੜੋ ਜਦੋਂ ਕੋਈ ਸਪਸ਼ਟ ਲੋੜ ਹੋਵੇ ਜੋ Postgres ਅਚчә ਤਰੀਕੇ ਨਾਲ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦਾ (ਉੱਚ-ਗੁਣਵੱਤਾ typo tolerance, ਰਿਚ autocomplete, ਭਾਰੀ faceting, ਜਾਂ ਉਹ ਲੋਡ ਜੋ ਮੁੱਖ ਡੀਬੀ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੋਵੇ)।
What’s the quickest decision rule for Postgres FTS vs a dedicated engine?
ਸਧਾਰਣ ਨਿਯਮ ਇਹ ਹੈ: ਜੇ ਤੁਸੀਂ ਇਹ ਤਿੰਨ ਚੈੱਕ ਪਾਸ ਕਰ ਲੈਂਦੇ ਹੋ ਤਾਂ Postgres ਵਿੱਚ ਹੀ ਰਹੋ:
- Relevance needs: “ਚੰਗਾ-ਕਾਫ਼ੀ” ranking ਕਾਬਿਲ-ਏ-ਕਬੂਲ ਹੈ।
- Load + latency: ਖੋਜ ਤੁਹਾਡੇ ਪ੍ਰਾਇਮਰੀ DB ਨੂੰ ਭਾਰੀ ਨਹੀਂ ਕਰ ਰਹੀ।
- Complexity: ਤੁਸੀਂ ਕੁਝ ਟੈਕਸਟ ਫੀਲਡਾਂ ਅਤੇ ਕੁਝ ਫਿਲਟਰਾਂ ਨਾਲ ਖੋਜ ਕਰ ਰਹੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਇਕ ਲਈ ਬਹੁਤ ਬੁਰਾ ਫੇਲ ਹੁੰਦੇ ਹੋ (ਖ਼ਾਸ ਕਰਕੇ typos/autocomplete ਜਾਂ ਉੱਚ ਖੋਜ ਟ੍ਰੈਫਿਕ), ਤਾਂ ਇਕ ਅਲੱਗ ਇੰਜਣ ਬਾਰੇ ਸੋਚੋ।
What kinds of search problems are a good fit for PostgreSQL full-text search?
Postgres FTS ਉਚਿਤ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਖੋਜ ਦੇ ਮਕਸਦ ਮੁੱਖ ਤੌਰ 'ਤੇ “ਸਹੀ ਰਿਕਾਰਡ ਲੱਭੋ” ਹੋਣ ਅਤੇ ਉਹ ਕੁਝ ਫੀਲਡਾਂ (title/body/notes) ਅਤੇ ਸਧਾਰਣ ਫਿਲਟਰਾਂ (tenant, status, category) 'ਤੇ ਨਿਰਭਰ ਹੋ।
ਇਹ help centers, internal docs, tickets, blog/article search, ਅਤੇ SaaS dashboards ਲਈ ਵਧੀਆ ਹੈ ਜਿੱਥੇ ਯੂਜ਼ਰ ਪਰੋਜੈਕਟ ਨਾਂ ਅਤੇ ਨੋਟਸ ਤੋਂ ਖੋਜ ਕਰਦੇ ਹਨ।
What’s a good “starter query” shape for Postgres full-text search?
ਇੱਕ ਚੰਗੀ ਬੇਸਲਾਈਨ ਕੁਐਰੀ ਆਮਤੌਰ 'ਤੇ:
- ਯੂਜ਼ਰ ਇਨਪੁਟ ਨੂੰ
websearch_to_tsquery ਨਾਲ parse ਕਰਦੀ ਹੈ।
How do I make Postgres search fast without adding more infrastructure?
ਪਹਿਲਾਂ ਇੱਕ prebuilt tsvector ਸਟੋਰ ਕਰੋ ਅਤੇ ਉਸ 'ਤੇ GIN ਇੰਡੈਕਸ ਲਗਾਓ। ਇਹ ਹਰ ਰਿਕੁਇਸਟ 'ਤੇ to_tsvector(...) ਨੂੰ ਦੁਹਰਾਉਣ ਤੋਂ ਬਚਾਂਦਾ ਹੈ।
ਵਹਿਮੀ ਰਚਨਾ:
Should I use a generated column or a trigger to maintain the tsvector?
ਜਦੋਂ ਖੋਜ ਦਸਤਾਵੇਜ਼ ਉਸੇ ਰੋ ਦੀ ਕਾਲਮਾਂ ਤੋਂ ਬਣਦਾ ਹੈ ਤਾਂ generated column ਸਭ ਤੋਂ ਸਿੱਧਾ ਵਿਕਲਪ ਹੈ। ਇਹ ਆਪਣੇ ਆਪ ਸਹੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ update ਹੋਣ 'ਤੇ ਭੁੱਲਣਾ ਮੁਸ਼ਕਿਲ ਹੁੰਦੀ ਹੈ।
ਜਦੋਂ ਦਸਤਾਵੇਜ਼ related tables 'ਤੇ ਨਿਰਭਰ ਹੋਵੇ (ਜਿਵੇਂ product ਨਾਲ ਉਸਦੀ category), ਜਾਂ ਤੁਸੀਂ custom logic ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ trigger-maintained tsvector ਵਰਤੋ। Trigger ਕੁਝ ਹਿੱਸੇ ਜੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਛੋਟੇ ਰੱਖੋ ਅਤੇ ਪਰਖੋ।
How can I improve relevance without overengineering ranking?
ਸੰਪੂਰਨ relevance ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਣ ਨਿਯਮ:
- Field weighting: title ਵਿੱਚ ਮِلਣ body ਨਾਲੋਂ ਵੱਧ ਗਿਣੋ।
- Boosts ਨਰਮ ਰੱਖੋ: freshness/popularity ਸ਼ਾਮਲ ਕਰਦੇ ਸਮੇਂ ਟੈਕਸਟ relevance ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਾ ਦਿਓ।
- ਸਹੀ ਭਾਸ਼ਾ config: stemming/stop words
run/running ਵਰਗੇ queries ਲਈ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ।
ਫਿਰ ਇੱਕ ਛੋਟੀ ਯੂਜ਼ਰ ਕੈਸੇ ਦੀ ਲਿਸਟ ਨਾਲ ਟੈਸਟ ਕਰੋ ਅਤੇ ਵਧੀਆ/ਖ਼ਰਾਬ ਹੋਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨੋਟ ਕਰੋ।
Why doesn’t Postgres FTS behave like “contains” search (LIKE %term%)?
Postgres FTS ਸ਼ਬਦ-ਅਧਾਰਤ ਹੈ, substring-ਅਧਾਰਤ ਨਹੀਂ। ਇਸ ਲਈ ਇਹ LIKE '%term%' ਵਰਗਾ ਨਹੀਂ ਚਲੇਗਾ।
ਜੇ ਤੁਹਾਨੂੰ substring search (IDs, codes, fragments) ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਉਸ ਲਈ ਆਮ ਤੌਰ 'ਤੇ trigram indexing ਵਰਤੀ ਜਾਂਦੀ ਹੈ ਜਾਂ ਹੋਰ ਹਥਿਆਰ/ਟੂਲ ਵਰਤੋ, ਨਾ ਕਿ FTS ਨੂੰ ਇਸ ਕੰਮ 'ਤੇ ਮਜਬੂਰ ਕਰੋ।
What are the red flags that mean I should add a dedicated search engine?
ਆਮ ਸੰਕੇਤ ਜੋ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਸੀਂ Postgres FTS ਤੋਂ ਅੱਗੇ ਵਧ ਚੁੱਕੇ ਹੋ:
- ਤੁਹਾਨੂੰ ਮਜ਼ਬੂਤ typo tolerance, synonyms, ਜਾਂ ਰਿਚ autocomplete ਲਾਜ਼ਮੀ ਚਾਹੀਦੀ ਹੈ।
- ਤੁਹਾਨੂੰ ਤੇਜ਼ counts ਵਾਲੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ facets/aggregations ਚਾਹੀਦੀਆਂ ਹਨ।
- ਖੋਜ ਟ੍ਰੈਫਿਕ ਇੰਨੀ ਵੱਧ ਹੈ ਕਿ ਉਹ ਤੁਹਾਡੇ ਪ੍ਰਾਇਮਰੀ DB ਨੂੰ ਭਾਰੀ ਕਰ ਰਿਹਾ ਹੈ।
- ਤੁਹਾਨੂੰ advanced relevance tooling (ਫੀਡਬੈਕ ਲੂਪ, learning-to-rank) ਦੀ ਲੋੜ ਹੈ।
ਵਿਹਾਰਤਮਕ ਰਾਸ਼ਤਾ ਇਹ ਹੈ ਕਿ Postgres ਨੂੰ source-of-truth ਰੱਖੋ ਅਤੇ ਜਦੋਂ ਲੋੜ ਸਾਫ਼ ਹੋਵੇ ਤਾਂ async indexing ਨਾਲ ਨਵਾਂ ਇੰਜਣ ਸ਼ੁਰੂ ਕਰੋ।
ts_rank (ਯਾ ts_rank_cd) ਵਰਤ ਕੇ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰੋਜ਼ ਨੂੰ ਉੱਪਰ ਰੱਖ ਸਕਦੇ ਹੋ।\n\nਭਾਸ਼ਾ configuration ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ Postgres ਨੂੰ ਸ਼ਬਦਾਂ ਨੂੰ ਕਿਵੇਂ ਸਲਾਹ ਦੇਣੀ ਹੈ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਸਹੀ config ਨਾਲ, "running" ਅਤੇ "run" ਮਿਲ ਸਕਦੇ ਹਨ (stemming), ਅਤੇ ਆਮ filler words ਅਣਡਿੱਠੇ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ (stop words)। ਗਲਤ config ਨਾਲ, ਖੋਜ ਟੁੱਟੀ ਹੋਈ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਆਮ ਯੂਜ਼ਰ ਸ਼ਬਦਾਂ ਨਾਲ ਕੋਈ ਮੇਲ ਨਹੀਂ ਹੋ ਰਿਹਾ।\n\nPrefix matching ਉਹ ਫੀਚਰ ਹੈ ਜੋ ਲੋਕ typeahead-ਜਿਹਾ ਵਿਹਾਰ ਚਾਹੁੰਦੇ ਸਮੇਂ ਲੱਭਦੇ ਹਨ, ਜਿਵੇਂ "dev" ਨੂੰ "developer" ਨਾਲ ਮਿਲਾਉਣਾ। Postgres FTS ਵਿਚ ਇਹ ਆਮਤੌਰ 'ਤੇ prefix operator ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਉదਾਹਰਨ ਲਈ term:*)। ਇਹ ਮਹਿਸੂਸ ਕੀਤੀ ਗਈ ਗੁਣਵੱਤਾ ਵਧਾ ਸਕਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਹ ਹਰ ਕੁਐਰੀ 'ਤੇ ਕੰਮ ਵਧਾ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਆਪਸ਼ਨਲ ਅਪਗ੍ਰੇਡ ਸਮਝੋ, ਡਿਫੌਲਟ ਨਹੀਂ।\n\nPostgres ਜੋ ਨਹੀਂ ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ: ਹਰ ਇੱਕ ਫੀਚਰ ਵਾਲਾ ਇੱਕ ਪੂਰਾ search ਪਲੇਟਫਾਰਮ। ਜੇ ਤੁਹਾਨੂੰ fuzzy spelling correction, advanced autocomplete, learning-to-rank, ਫੀਲਡ-ਵੱਖ-ਵੱਖ complex analyzers, ਜਾਂ distributed indexing across many nodes ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਸੀਂ built-in comfort zone ਦੇ ਬਾਹਰ ਹੋ। ਫਿਰ ਵੀ, ਕਈ ਐਪਾਂ ਲਈ PostgreSQL FTS ਉਪਭੋਗਤਿਆਂ ਦੀ ਉਮੀਦ ਦਾ ਜ਼ਿਆਦਾ ਹਿੱਸਾ ਘੱਟ ਮੂਵਿੰਗ ਪਾਰਟਸ ਨਾਲ ਦੇ ਦਿੰਦਾ ਹੈ।\n\n## ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਕੁਐਰੀ ਜੋ ਤੁਸੀਂ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਅਨੁਕੂਲ ਕਰ ਸਕਦੇ ਹੋ\n\nਹੇਠਾਂ ਇੱਕ ਛੋਟੀ, ਹਕੀਕਤ-ਨੂੰ-ਨਜ਼ਰ ਵਿੱਚ ਰੱਖਣਯੋਗ ਰਚਨਾ ਹੈ ਜੋ ਤੁਸੀਂ ਖੋਜ ਲਈ ਵਰਤ ਸਕਦੇ ਹੋ:\n\nsql\n-- Minimal example table\nCREATE TABLE articles (\n id bigserial PRIMARY KEY,\n title text NOT NULL,\n body text NOT NULL,\n updated_at timestamptz NOT NULL DEFAULT now()\n);\n\n\nPostgreSQL full-text search ਲਈ ਇੱਕ ਚੰਗਾ ਬੇਸਲਾਈਨ ਇਹ ਹੈ: ਯੂਜ਼ਰ ਦੇ ਲਿਖੇ ਟੈਕਸਟ ਤੋਂ ਇੱਕ ਕੁਐਰੀ ਬਣਾਓ, rows ਨੂੰ ਪਹਿਲਾਂ filter ਕਰੋ (ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ), ਫਿਰ ਬਾਕੀ matches ਨੂੰ rank ਕਰੋ।\n\nsql\n-- $1 = user search text, $2 = limit, $3 = offset\nWITH q AS (\n SELECT websearch_to_tsquery('english', $1) AS query\n)\nSELECT\n a.id,\n a.title,\n a.updated_at,\n ts_rank_cd(\n setweight(to_tsvector('english', coalesce(a.title, '')), 'A') ||\n setweight(to_tsvector('english', coalesce(a.body, '')), 'B'),\n q.query\n ) AS rank\nFROM articles a\nCROSS JOIN q\nWHERE\n a.updated_at >= now() - interval '2 years' -- example safe filter\n AND (\n setweight(to_tsvector('english', coalesce(a.title, '')), 'A') ||\n setweight(to_tsvector('english', coalesce(a.body, '')), 'B')\n ) @@ q.query\nORDER BY rank DESC, a.updated_at DESC, a.id DESC\nLIMIT $2 OFFSET $3;\n\n\nਕੁਝ ਵਿਸਥਾਰ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸਮਾਂ ਬਚਾਉਂਦੇ ਹਨ:\n\n- ਸਸਤੇ ਫਿਲਟਰਾਂ ਨੂੰ WHERE ਵਿੱਚ ਰੱਖੋ ਪਹਿਲਾਂ ranking ਤੋਂ ਪਹਿਲਾਂ (status, tenant_id, date ranges). ਤੁਸੀਂ ਘੱਟ rows ਨੂੰ rank ਕਰੋਗੇ, ਇਸ ਲਈ ਤੇਜ਼ ਰਹਿੰਦਾ ਹੈ।\n- ਹਮੇਸ਼ਾਂ ORDER BY ਵਿੱਚ ਇੱਕ tie-breaker ਸ਼ਾਮਿਲ ਕਰੋ (ਜਿਵੇਂ updated_at, ਫਿਰ id)। ਇਹ pagination ਨੂੰ stable ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਬਹੁਤ ਨਤੀਜੇ ਇੱਕੋ rank ਰੱਖਦੇ ਹਨ।\n- ਯੂਜ਼ਰ ਇਨਪੁਟ ਲਈ websearch_to_tsquery ਵਰਤੋ। ਇਹ quotes ਅਤੇ ਸਧਾਰਣ operators ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਹੇਠਾਂ ਲੈਦਾ ਹੈ ਜਿਸ ਤਰੀਕੇ ਨਾਲ ਲੋਕ ਉਮੀਦ ਕਰਦੇ ਹਨ।\n\nਇਸ ਬੇਸਲਾਈਨ ਦੇ ਚੱਲਣ 'ਤੇ, to_tsvector(...) ਪ੍ਰਗਟਾਵਾਂ ਨੂੰ ਇੱਕ stored column ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਰਹਿਣ ਦਿਓ। ਇਹ ਹਰ ਕੁਐਰੀ 'ਤੇ ਦੁਹਰਾਉ ਕਰਨ ਤੋਂ ਬਚਾਏਗਾ ਅਤੇ ਇੰਡੈਕਸਿੰਗ ਸਪੱਸ਼ਟ ਕਰੇਗਾ।\n\n## ਇੰਡੈਕਸਿੰਗ ਸੈਟਅੱਪ ਜੋ ਆਮਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ\n\nਜ਼ਿਆਦਾਤਰ "PostgreSQL full-text search slow ਹੈ" ਵਾਲੀਆਂ ਕਹਾਣੀਆਂ ਇੱਕ ਗੱਲ ਨਾਲ ਨਿਭਦੀਆਂ ਹਨ: ਡੇਟਾਬੇਸ ਹਰ ਕੁਐਰੀ 'ਤੇ search document ਬਣਾ ਰਹੀ ਹੈ। ਪਹਿਲਾਂ ਇਹ ਠੀਕ ਕਰੋ — ਇੱਕ prebuilt tsvector ਸਟੋਰ ਕਰਕੇ ਅਤੇ ਉਸ ਦਾ ਇੰਡੈਕਸ ਬਣਾਕੇ।\n\n### tsvector ਸਟੋਰ ਕਰੋ: generated column ਜਾਂ trigger?\n\nਜਦੋਂ ਤੁਹਾਡਾ search document ਇੱਕੋ ਰੋ ਦੇ ਕਾਲਮਾਂ ਤੋਂ ਬਣਦਾ ਹੈ, generated column ਸਭ ਤੋਂ ਸਿੱਧਾ ਵਿਕਲਪ ਹੈ। ਇਹ updates 'ਤੇ ਆਪਣੇ ਆਪ ਸਹੀ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਭੁੱਲਨਾ ਮੁਸ਼ਕਿਲ ਹੁੰਦਾ ਹੈ।\n\nਜਦੋਂ ਦਸਤਾਵੇਜ਼ related tables 'ਤੇ ਨਿਰਭਰ ਹੋਵੇ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ product row ਨੂੰ ਉਸਦੀ category name ਨਾਲ ਜੋੜਨਾ), ਜਾਂ ਜਦੋਂ ਤੁਸੀਂ ਐਸਾ custom logic ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਇੱਕ generated expression ਵਿੱਚ ਅਸਾਨੀ ਨਾਲ ਨਹੀਂ ਫਿੱਟ ਹੁੰਦੀ, ਤਾਂ trigger-maintained tsvector ਵਰਤੋ। Triggers ਮੂਵਿੰਗ ਪਾਰਟਸ ਜੋੜਦੇ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਛੋਟੇ ਰੱਖੋ ਅਤੇ ਟੈਸਟ ਕਰੋ।\n\n### ਤੁਸੀਂ ਜਿਸ ਇੰਡੈਕਸ ਨੂੰ ਲਗਭਗ ਹਮੇਸ਼ਾਂ ਚਾਹੁੰਦੇ ਹੋ\n\ntsvector ਕਾਲਮ 'ਤੇ GIN ਇੰਡੈਕਸ ਬਣਾਓ। ਇਹ ਬੇਸਲਾਈਨ ਹੈ ਜੋ ਆਮ ਐਪ ਖੋਜ ਲਈ PostgreSQL FTS ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ।\n\nਕਈ ਐਪਾਂ ਲਈ ਕੰਮ ਕਰਨ ਵਾਲੀ ਸੈਟਅੱਪ:\n\n- searchable tsvector ਉਸੀ ਟੇਬਲ ਵਿੱਚ ਰੱਖੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਬਹੁਤ ਵਾਰ ਖੋਜਦੇ ਹੋ।ਉਸ tsvector ਤੇ GIN ਇੰਡੈਕਸ ਸ਼ਾਮਿਲ ਕਰੋ।ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀ ਕੁਐਰੀ stored tsvector ਖਿਲਾਫ਼ @@ ਵਰਤਦੀ ਹੈ, ਨਾ ਕਿ on-the-fly to_tsvector(...)।ਵੱਡੇ backfills ਤੋਂ ਬਾਅਦ VACUUM (ANALYZE) 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਤਾਂ ਕਿ planner ਨਵੇਂ ਇੰਡੈਕਸ ਨੂੰ ਸਮਝ ਸਕੇ।\n\nਉਸੇ ਟੇਬਲ ਵਿੱਚ vector ਰੱਖਣਾ ਆਮਤੌਰ 'ਤੇ ਤੇਜ਼ ਤੇ ਸਧਾਰਣ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਵੱਖਰੀ search table ਤਦ ਠੀਕ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ base table ਬਹੁਤ ਲਿਖਤ-ਭਾਰ ਵਾਲੀ ਹੋਵੇ, ਜਾਂ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ combined document index ਕਰਦੇ ਹੋ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਟੇਬਲਾਂ 'ਚ ਫੈਲਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਆਪਣੀ ਸੂਚੀ ਅਨੁਸਾਰ ਅਪਡੇਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।\n\nPartial indexes ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਕੁਝ rows ਨੂੰ search ਕਰਦੇ ਹੋ, ਜਿਵੇਂ status = 'active', ਇੱਕ single tenant multi-tenant app ਵਿੱਚ, ਜਾਂ ਇੱਕ ਖ਼ਾਸ ਭਾਸ਼ਾ ਲਈ। ਇਹ ਇੰਡੈਕਸ ਸਾਈਜ਼ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ searches ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ਼ ਜੇ ਤੁਹਾਡੀਆਂ queries ਹਮੇਸ਼ਾਂ ਉਹੀ ਫਿਲਟਰ ਸ਼ਾਮਿਲ ਕਰਦੀਆਂ ਹਨ।\n\n## ਬਿਨਾਂ ਅਤਿ-ਅਭਿਆਸ ਦੇ ਕਬੂਲਯੋਗ relevance ਪ੍ਰਾਪਤ ਕਰਨਾ\n\nਜੇ ਤੁਸੀਂ relevance ਨਿਯਮਾਂ ਨੂੰ ਸਧਾਰਣ ਅਤੇ predictable ਰੱਖਦੇ ਹੋ ਤਾਂ PostgreSQL FTS ਨਾਲ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਨਤੀਜੇ ਮਿਲ ਸਕਦੇ ਹਨ।\n\nਸਭ ਤੋਂ ਆਸਾਨ ਜਿੱਤ field weighting ਹੈ: title ਵਿੱਚ ਮਿਲਣਾ body ਵਿੱਚ ਮਿਲਣ ਨਾਲ ਵੱਧ ਮਾਇਨੇ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। title ਨੂੰ ਵਧੇਰੇ weight ਦੇ ਕੇ ਇੱਕ combined tsvector ਬਣਾਓ, ਫਿਰ ts_rank ਜਾਂ ts_rank_cd ਨਾਲ rank ਕਰੋ।\n\nਜੇ ਤੁਸੀਂ "fresh" ਜਾਂ "popular" ਆਈਟਮਾਂ ਨੂੰ ਥੋੜ੍ਹਾ ਉਪਰ ਉਹਨਾਂ ਨੂੰ ਆਉਣ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਇਹ ਧਿਆਨ ਨਾਲ ਕਰੋ। ਇੱਕ ਛੋਟਾ ਬੂਸਟ ਠੀਕ ਹੈ, ਪਰ ਇਸਨੂੰ text relevance 'ਤੇ ਕਬਜ਼ਾ ਨਹੀਂ ਕਰਨ ਦਿਓ। ਇੱਕ ਕਾਰਗਰ pattern ਇਹ ਹੈ: ਪਹਿਲਾਂ text ਨਾਲ rank ਕਰੋ, ਫਿਰ ties ਨੂੰ recency ਨਾਲ ਤੋੜੋ, ਜਾਂ ਇੱਕ capped bonus ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਕਿ ਬਿਲਕੁਲ irrelevant ਨਵਾਂ ਆਈਟਮ ਇਕ ਪੁਰਾਣੇ perfect match ਨੂੰ ਹਰਾ ਨਾ ਦੇਵੇ।\n\nSynonyms ਅਤੇ phrase matching ਉਮੀਦਾਂ ਨੂੰ ਅਕਸਰ ਵੱਖਰਾ ਕਰ ਦਿੰਦੇ ਹਨ। Synonyms ਆਪਣੇ ਆਪ ਨਹੀਂ ਮਿਲਦੇ; ਤੁਸੀਂ thesaurus ਜਾਂ custom dictionary ਜੋੜਦੇ ਹੋ, ਜਾਂ query terms ਨੂੰ ਖੁਦ ਵਧਾਉਂਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ "auth" ਨੂੰ "authentication" ਸਮਝਣਾ)। Phrase matching ਵੀ ਡਿਫ਼ੌਲਟ ਨਹੀਂ ਹੁੰਦੀ: ਸਧਾਰਨ queries ਸ਼ਬਦਾਂ ਨੂੰ ਕਿਤੇ ਵੀ ਮਿਲਾਉਂਦੇ ਹਨ, ਨਾ ਕਿ "ਇਹ ਐਕਸੈਕਟ ਫਰੇਜ਼"। ਜੇ ਯੂਜ਼ਰ quoted phrases ਜਾਂ ਲੰਬੇ ਪ੍ਰਸ਼ਨ ਟਾਈਪ ਕਰਦੇ ਹਨ, ਤਾਂ phraseto_tsquery ਜਾਂ websearch_to_tsquery ਬਾਰੇ ਸੋਚੋ ਤਾਂ ਜੋ ਖੋਜ ਲੋਕਾਂ ਦੀ ਤਰੀਕੇ ਨਾਲ ਮਿਲੇ।\n\nਮਿਸ਼ਰ-ਭਾਸ਼ਾਈ ਸਮੱਗਰੀ ਲਈ ਲੋੜ ਇੱਕ ਫੈਸਲਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਦਸਤਾਵੇਜ਼ ਪ੍ਰਤੀ ਭਾਸ਼ਾ ਪਤਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਸਟੋਰ ਕਰੋ ਅਤੇ tsvector ਨੂੰ ਸਹੀ configuration (English, Russian, ਆਦਿ) ਨਾਲ ਬਣਾਓ। ਜੇ ਨਹੀਂ, ਤਾਂ ਇੱਕ ਸੁਰੱਖਿਅਤ fallback simple configuration (ਕੋਈ stemming ਨਹੀਂ) ਨਾਲ index ਕਰਨਾ ਹੈ, ਜਾਂ ਦੋ vector ਰੱਖੋ: ਇੱਕ ਭਾਸ਼ਾ-ਵਿਸ਼ੇਸ਼ ਜਦੋਂ ਪਤਾ ਹੋਵੇ, ਇੱਕ simple ਸਭ ਲਈ।\n\nRelevance ਨੂੰ ਪਰਖਣ ਲਈ, ਇਸਨੂੰ ਛੋਟਾ ਅਤੇ konkreਟ ਰੱਖੋ:\n\n- ਯੂਜ਼ਰਾਂ ਤੋਂ 10 ਤੋਂ 20 ਅਸਲੀ queries ਇਕੱਠੇ ਕਰੋ (ਜਾਂ support chats)।ਉਹ 1 ਤੋਂ 3 ਨਤੀਜੇ ਲਿਖੋ ਜੋ top 'ਤੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।ਹਰ ਟਿਊਨਿੰਗ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਉਨ੍ਹਾਂ ਨੂੰ ਚਲਾਓ ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਕੀ ਵਧਿਆ ਜਾਂ ਖਰਾਬ ਹੋਇਆ।ਜਦੋਂ ਇਹ ਤੁਹਾਡੇ ਐਪ ਲਈ ਕਾਫ਼ੀ ਚੰਗਾ ਲੱਗੇ ਤਾਂ ਰੁਕ ਜਾਓ।\n\nਅਕਸਰ ਇਹ Postgres FTS ਲਈ ਬਹੁਤ ਹੁੰਦਾ ਹੈ ਐਪ ਖੋਜ ਬਾਕਸਾਂ ਜਿਵੇਂ "templates", "docs", ਜਾਂ "projects"।\n\n## ਆਮ ਗਲਤੀਆਂ ਜੋ Postgres ਖੋਜ ਨੂੰ ਖਰਾਬ ਦਿਖਾਉਂਦੀਆਂ ਹਨ\n\nਜ਼ਿਆਦਾਤਰ "PostgreSQL FTS slow ਜਾਂ irrelevant" ਵਾਲੀਆਂ ਕਹਾਣੀਆਂ ਕੁਝ ਟਾਲੀ-ਜੋਗ ਗਲਤੀਆਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਠੀਕ ਕਰਨਾ ਆਮਤੌਰ 'ਤੇ ਨਵੇਂ search ਸਿਸਟਮ ਜੋੜਨ ਨਾਲੋਂ ਸੌਖਾ ਹੁੰਦਾ ਹੈ।\n\nਇੱਕ ਆਮ ਜਾਲ tsvector ਨੂੰ ਇੱਕ computed value ਸਮਝਣਾ ਹੈ ਜੋ ਆਪਣੇ ਆਪ ਸਹੀ ਰਹਿੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ tsvector ਨੂੰ ਇੱਕ column ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹੋ ਪਰ ਹਰ insert/update 'ਤੇ ਅਪਡੇਟ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਨਤੀਜੇ ਬੇਠਕੇ ਲੱਗਣਗੇ ਕਿਉਂਕਿ ਇੰਡੈਕਸ ਟੈਕਸਟ ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਨਹੀਂ ਰਹੇਗਾ। ਜੇ ਤੁਸੀਂ query ਵਿੱਚ to_tsvector(...) ਨੂੰ on-the-fly ਗਣਨਾ ਕਰਦੇ ਹੋ ਤਾਂ ਨਤੀਜੇ ਸਹੀ ਹੋ ਸਕਦੇ ਹਨ ਪਰ ਧੀਮੇ; ਅਤੇ ਤੁਸੀਂ ਇੱਕ dedicated index ਦਾ ਲਾਭ ਖੋ ਸਕਦੇ ਹੋ।\n\nਹੋਰ ਇੱਕ ਆਸਾਨ ਤਰੀਕਾ ਜਿਸ ਨਾਲ performance ਖ਼ਰਾਬ ਹੁੰਦੀ ਹੈ, ਉਹ ਹੈ narrowing candidate set ਤੋਂ ਪਹਿਲਾਂ ranking ਕਰਨਾ। ts_rank ਲਾਭਕਾਰੀ ਹੈ, ਪਰ ਆਮਤੌर 'ਤੇ ਇਹ ਅਸੀਂ index ਨੂੰ ਵਰਤ ਕੇ matching rows ਪਾਉਣ ਤੋਂ ਬਾਅਦ ਚਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਵੱਡੇ ਹਿੱਸੇ ਉੱਤੇ rank calculate ਕਰੋ (ਯਾ ਪਹਿਲਾਂ tables/join ਕਰੋ), ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਤੇਜ਼ ਖੋਜ ਨੂੰ table scan ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ।\n\nਲੋਕ contains search ਨੂੰ LIKE '%term%' ਵਾਂਗ ਵਿਚਾਰਦੇ ਹਨ। Leading wildcards full-text search ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਕਿਉਂਕਿ FTS ਸ਼ਬਦਾਂ (lexemes) 'ਤੇ ਆਧਾਰਿਤ ਹੈ, ਨਾ ਕਿ arbitrary substrings 'ਤੇ। ਜੇ ਤੁਹਾਨੂੰ substring search for product codes ਜਾਂ partial IDs ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਉਸ ਕੇਸ ਲਈ trigram indexing ਵਰਤੋ ਬਜਾਏ FTS ਨੂੰ ਦੋਸ਼ ਦੇਣ ਦੇ।\n\nPerformance ਮੁੱਦੇ ਅਕਸਰ matching ਨਹੀਂ, ਬਲਕਿ result handling ਤੋਂ ਆਉਂਦੇ ਹਨ। ਦੋ ਪੈਟਰਨ ਦੇਖੋ:\n\n- ਵੱਡਾ OFFSET pagination, ਜੋ ਜਿਵੇਂ ਜਿਵੇਂ ਤੁਸੀਂ ਪੇਜ ਕਰਦੇ ਹੋ Postgres ਨੂੰ ਹੋਰ ਅਤੇ ਹੋਰ rows skip ਕਰਵਾਉਂਦਾ ਹੈ।Unbounded result sets, ਜਿੱਥੇ ਕੁਐਰੀ ਦਹਜਾਰਾਂ rows ਵਾਪਸ ਕਰ ਸਕਦੀ ਹੈ।\n\nਪਰੇਸ਼ਨਲ ਮੁੱਦੇ ਵੀ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ updates ਤੋਂ ਬਾਅਦ index bloat ਬਣ ਸਕਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ reindex ਕਰਦੇ ਹੋ ਤਾਂ ਇਹ ਮਹਿੰਗਾ ਪੈ ਸਕਦਾ ਹੈ। ਅਸਲ query ਸਮੇਂ ਮਾਪੋ (ਅਤੇ EXPLAIN ANALYZE ਚੈੱਕ ਕਰੋ) ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ। ਬਿਨਾਂ ਨੰਬਰਾਂ ਦੇ, ਆਸਾਨੀ ਨਾਲ ਤੁਸੀਂ PostgreSQL FTS ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਕੇ ਕਿਸੇ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ ਗਲਤ ਕਰ ਸਕਦੇ ਹੋ।\n\n## ਤੇਜ਼ ਚੈੱਕਲਿਸਟ: ਕੁਏਰੀ ਅਤੇ ਇੰਡੈਕਸਿੰਗ ਸੈਨਟੀ ਚੈਕ\n\nPostgreSQL FTS ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਚੈੱਕ ਕਰੋ। ਜ਼ਿਆਦਾਤਰ ਮੁੱਦੇ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਤੋਂ ਹੁੰਦੇ ਹਨ, ਫੀਚਰ ਖ਼ੁਦ ਤੋਂ ਨਹੀਂ।\n\n### ਡੇਟਾ + ਇੰਡੈਕਸ ਸੈਨਟੀ ਚੈਕ\n\nਇੱਕ ਅਸਲੀ tsvector ਬਣਾਓ: ਇਸਨੂੰ generated ਜਾਂ maintained column ਵਿੱਚ ਸਟੋਰ ਕਰੋ (ਹਰ ਕੁਐਰੀ 'ਤੇ ਗਣਨਾ ਨਾ ਕਰੋ), ਸਹੀ ਭਾਸ਼ਾ config (english, simple, ਆਦਿ) ਵਰਤੋਂ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਫੀਲਡਾਂ ਨੂੰ ਮਿਲਾ ਰਹੇ ਹੋ ਤਾਂ weights ਲਗਾਓ (title > subtitle > body)।\n\nਜੋ ਤੁਸੀਂ ਇੰਡੈਕਸ ਕਰਦੇ ਹੋ ਉਸਨੂੰ ਸਧਾਰਨ ਕਰੋ: noisy fields (IDs, boilerplate, navigation text) ਨੂੰ tsvector ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਅਤੇ huge blobs ਨੂੰ trim ਕਰੋ ਜੇ ਯੂਜ਼ਰ ਕਦੇ ਨਹੀਂ ਖੋਜਦੇ।\n\nਸਹੀ ਇੰਡੈਕਸ ਬਣਾਓ: tsvector column 'ਤੇ GIN ਇੰਡੈਕਸ ਸ਼ਾਮਿਲ ਕਰੋ ਅਤੇ EXPLAIN 'ਚ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਜੇ ਸਿਰਫ਼ ਇੱਕ subset searchable ਹੈ (ਉਦਾਹਰਨ status = 'published'), ਤਾਂ partial index ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਫਰਕ ਪਾ ਸਕਦਾ ਹੈ।\n\nਟੇਬਲਾਂ ਨੂੰ ਸਿਹਤਮੰਦ ਰੱਖੋ: dead tuples index scans ਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦੇ ਹਨ। ਰੈਗੁਲਰ vacuuming ਜ਼ਰੂਰੀ ਹੁੰਦੀ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਜ਼ਿਆਦਾ ਅਪਡੇਟ ਵਾਲੀ ਸਮੱਗਰੀ 'ਤੇ।\n\nਇੱਕ reindex ਯੋਜਨਾ ਰੱਖੋ: ਵੱਡੀਆਂ migrations ਜਾਂ bloat ਹੋਏ indexes ਕਈ ਵਾਰੀ controlled reindex ਦੀ ਲੋੜ ਕਰਦੇ ਹਨ।\n\nਜਦੋਂ ਡੇਟਾ ਅਤੇ ਇੰਡੈਕਸ ਠੀਕ ਲੱਗਣ, ਤਾਂ ਕੁਐਰੀ ਦੀ ਆਕਾਰ ਤੇ ਧਿਆਨ ਦਿਓ। PostgreSQL FTS ਤੇਜ਼ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ candidate set ਨੂੰ ਜਲਦੀ ਤੌਰ 'ਤੇ ਘਟਾ ਸਕਦਾ ਹੈ।\n\n### ਕੁਐਰੀ + ਰਨਟਾਈਮ ਸੈਨਟੀ ਚੈਕ\n\nਪਹਿਲਾਂ filter, ਫਿਰ rank: ਸਖਤ filters (tenant, language, published, category) ranking ਤੋਂ ਪਹਿਲਾਂ ਲਗਾਓ। ਹਜ਼ਾਰਾਂ rows 'ਤੇ ranking ਕਰੋ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਰੱਦ ਕਰ ਦਿਓਗੇ, ਬੇਕਾਰ ਕਾm ਹੈ।\n\nStable ordering ਵਰਤੋ: rank ਅਤੇ ਫਿਰ tie-breaker ਜਿਵੇਂ updated_at ਜਾਂ id ਨਾਲ order ਕਰੋ ਤਾਂ ਕਿ ਨਤੀਜੇ refreshes ਦੌਰਾਨ ਨਹੀਂ ਹਿਲਦੇ।\n\n"ਕੁਐਰੀ ਸਭ ਕੁਝ ਕਰਦੀ ਹੈ" ਤੋਂ ਬਚੋ: ਜੇ ਤੁਹਾਨੂੰ fuzzy matching ਜਾਂ typo tolerance ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਇਰਾਦੇ ਨਾਲ ਕਰੋ (ਅਤੇ ਮਾਪੋ)। ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ sequential scans ਨੂੰ ਮਜਬੂਰ ਨਾ ਕਰੋ।\n\nਅਸਲ queries ਦੀ ਪਰੀਖਿਆ ਕਰੋ: top 20 searches ਇਕੱਠੇ ਕਰੋ, relevance ਹੱਥ ਨਾਲ ਚੈੱਕ ਕਰੋ, ਅਤੇ regression ਫੜਨ ਲਈ ਇੱਕ ਛੋਟਾ expected-results ਸੂਚੀ ਰੱਖੋ।\n\nSlow paths 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ: slow queries ਲੌਗ ਕਰੋ, EXPLAIN (ANALYZE, BUFFERS) ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ index size ਅਤੇ cache hit rate ਦਾ ਮਾਨਟਰ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕੋ ਜਦੋਂ ਵਾਧਾ ਰਵੱਈਏ ਬਦਲ ਦੇਵੇ।\n\n## ਉਦਾਹਰਨ ਸਿਨਾਰਿਓ: ਬੁਨਿਆਦੀ site search ਤੋਂ ਵਧ ਰਹੀਆਂ ਲੋੜਾਂ ਤੱਕ\n\nਇੱਕ SaaS help center ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਵਧੀਆ ਜਗ੍ਹਾ ਹੈ ਕਿਉਂਕਿ ਟਾਰਗੇਟ ਸਾਫ਼ ਹੈ: ਲੋਕ ਇੱਕ ਲੇਖ ਲੱਭਨਾ ਚਾਹੁੰਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਦੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਵੇ। ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਹਜ਼ਾਰ ਲੇਖ ਹੋ ਸਕਦੇ ਹਨ, ਹਰ ਇੱਕ ਦਾ title, short summary, ਅਤੇ body text। ਜ਼ਿਆਦਾਤਰ ਵਿਜ਼ਟਰ 2-5 ਸ਼ਬਦ ਟਾਈਪ ਕਰਦੇ ਹਨ ਜਿਵੇਂ "reset password" ਜਾਂ "billing invoice"।\n\nPostgreSQL FTS ਨਾਲ, ਇਹ ਅਚਾਨਕ ਹੀ ਖਤਮ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ combined fields ਲਈ tsvector ਸਟੋਰ ਕਰੋ, GIN ਇੰਡੈਕਸ ਜੋੜੋ, ਅਤੇ relevance ਨਾਲ rank ਕਰੋ। ਸਫਲਤਾ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗੇਗੀ: ਨਤੀਜੇ 100 ms ਤੋਂ ਘੱਟ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, top 3 ਨਤੀਜੇ ਆਮਤੌਰ 'ਤੇ ਸਹੀ ਹਨ, ਅਤੇ ਤੁਹਾਨੂੰ ਸਿਸਟਮ ਨੂੰ ਬਾਰੀ-ਬਾਰੀ ਦੇਖਭਾਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।\n\nਫਿਰ ਪ੍ਰੋਡਕਟ ਵਧਦਾ ਹੈ। Support ਚਾਹੁੰਦਾ ਹੈ ਕਿ product area, platform (web, iOS, Android), ਅਤੇ plan (free, pro, business) ਨਾਲ filter ਕੀਤਾ ਜਾਵੇ। Docs ਲੇਖਕ synonyms, "did you mean", ਅਤੇ typo handling ਚਾਹੁੰਦੇ ਹਨ। Marketing analytics ਚਾਹੁੰਦੀ ਹੈ ਜਿਵੇਂ "top searches with zero results"। ਟ੍ਰੈਫਿਕ ਵਧਦੀ ਹੈ ਅਤੇ search ਇੱਕ ਸਭ ਤੋਂ ਥੱਕਾਉਂਦਾ endpoint ਬਣ ਜਾਂਦਾ ਹੈ।\n\nਇਹ ਉਹ ਸੰਕੇਤ ਹਨ ਜੋ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਇੱਕ ਸਮਰਪਿਤ search engine ਦਾ ਖ਼ਰਚ ਵਾਜਬ ਹੋ ਸਕਦਾ ਹੈ:\n\n- ਤੁਹਾਨੂੰ ਉਹੀ ਪేజ਼ 'ਤੇ ਬਹੁਤ ਸਾਰੇ filters ਅਤੇ facets ਚਾਹੀਦੇ ਹਨ ਜੋ full-text search ਨਾਲ ਇੱਕਠੇ ਦਰਸਾਉਣੇ ਹੋਣ।ਤੁਹਾਨੂੰ fuzzy matching, typo tolerance, ਜਾਂ autocomplete ਪਹਿਲੀ-ਕ਼ਿਸ਼ਤ ਵਜੋਂ ਚਾਹੀਦੀ ਹੈ।ਤੁਹਾਨੂੰ search analytics ਅਤੇ relevance ਲਈ ਫੀਡਬੈਕ ਲੂਪ ਚਾਹੀਦੀ ਹੈ।ਖੋਜ ਟ੍ਰੈਫਿਕ ਇੰਨਾ ਵੱਧ ਹੈ ਕਿ ਇਸਨੂੰ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ ਤੋਂ ਅਲੱਗ ਕਰਨ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।\n\nਇੱਕ ਵਿਆਵਹਾਰਿਕ migration ਰਸਤਾ ਇਹ ਹੈ ਕਿ Postgres ਨੂੰ source of truth ਵਜੋਂ ਰੱਖੋ, ਭਾਵੇਂ ਤੁਸੀਂ search engine ਸ਼ੁਰੂ ਕਰ ਦਿਓ। ਪਹਿਲਾਂ search queries ਅਤੇ no-result ਕੇਸ ਲੌਗ ਕਰੋ, ਫਿਰ ਇੱਕ async sync job ਚਲਾਉ ਜੋ ਸਿਰਫ searchable fields ਨੂੰ ਨਵੇਂ index ਵਿੱਚ ਕਾਪੀ ਕਰੇ। ਦੋਹਾਂ ਨੂੰ ਕੁਝ ਸਮਾਂ parallel ਚਲਾਉ ਅਤੇ ਆਹਿਸਤੋਂ switch ਕਰੋ, ਨਾ ਕਿ ਦਿਨ ਇੱਕ 'ਤੇ ਸਾਰਾ ਜੋਖਮ ਲਵੋ।\n\n## ਅਗਲੇ ਕਦਮ: ਇੱਕ ਬੇਸਲਾਈਨ ship ਕਰੋ, ਮਾਪੋ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ\n\nਜੇ ਤੁਹਾਡੀ ਖੋਜ ਮੁੱਖ ਤੌਰ 'ਤੇ "ਇਹ ਸ਼ਬਦ ਰੱਖਦੇ ਦਸਤਾਵੇਜ਼ ਲੱਭੋ" ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਡੈਟਾਸੈਟ ਵੱਡਾ ਨਹੀਂ ਹੈ, ਤਾਂ PostgreSQL FTS ਆਮਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ਇੱਥੇ ਸ਼ੁਰੂ ਕਰੋ, ਇਸਨੂੰ ਚਲਾਓ, ਅਤੇ ਸਿਰਫ਼ ਤਦ ਹੀ ਇੱਕ ਸਮਰਪਿਤ ਇੰਜਣ ਜੋੜੋ ਜਦੋਂ ਤੁਸੀਂ ਗੈਪ ਨੂੰ ਨਾਮ ਦੇ ਸਕੋ ਜਾਂ scaling ਦਰਦ ਨੂੰ ਨਾਂਪ ਸਕੋ।\n\nਇੱਕ ਯਾਦ ਰੱਖਣਯੋਗ ਸੰਖੇਪ:
\n- ਜਦੋਂ ਤੁਸੀਂ tsvector ਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ, GIN ਇੰਡੈਕਸ ਜੋੜ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੁਹਾਡੀਆਂ ranking ਲੋੜਾਂ ਬੁਨਿਆਦੀ ਹਨ, ਤਾਂ Postgres FTS ਵਰਤੋਂ।ਇੱਕ starter query ਅਤੇ ਇੱਕ index setup ship ਕਰੋ, ਫਿਰ ਅਸਲ latency ਅਤੇ "ਲੋਕ ਮਿਲੇ ਕਿ ਨਹੀਂ" measure ਕਰੋ।relevance ਨੂੰ ਛੋਟੇ, ਸਪੱਸ਼ਟ ਬਦਲਾਅ (weights, language config, query parsing) ਨਾਲ ਟਿਊਨ ਕਰੋ, ਨਾ ਕਿ ਵੱਡੇ rewrite ਨਾਲ।ਇੱਕ search engine ਦੀ ਯੋਜਨਾ ਉਸ ਵੇਲੇ ਬਣਾਓ ਜਦੋਂ ਤੁਸੀਂ ਸਪਸ਼ਟ ਗੈਪ (autocomplete, ਮਜ਼ਬੂਤ typo tolerance, faceting) ਜਾਂ ਵਾਧਾ ਦੇ ਨਿਸ਼ਾਨੇ (ਆਕਾਰ, ਲੋਡ) ਦੇਖੋ।\n\nਇਕ ਪ੍ਰਯੋਗਾਤਮਕ ਅਗਲਾ ਕਦਮ: ਪਹਿਲਾਂ ਦਿੱਤੀ ਸ਼ੁਰੂਆਤੀ ਕੁਐਰੀ ਅਤੇ ਇੰਡੈਕਸ ਲਾਗੂ ਕਰੋ, ਫਿਰ ਇੱਕ ਹਫ਼ਤੇ ਲਈ ਕੁਝ ਸਧਾਰਣ metrics ਲੌਗ ਕਰੋ। p95 query time, slow queries, ਅਤੇ ਇੱਕ ਸਧਾਰਣ success signal ਜਿਵੇਂ "search -> click -> ਕੋਈ ਤੁਰੰਤ bounce ਨਹੀਂ" (ਇੱਕ ਆਧਾਰਭੂਤ event counter ਵੀ ਕਾਫੀ ਹੈ) ਟਰੈਕ ਕਰੋ। ਤੁਹਾਨੂੰ ਜਲਦੀ ਪਤਾ ਲੱਗ ਜੇ ਤੁਹਾਨੂੰ ਬਿਹਤਰ ranking ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਬਿਹਤਰ UX (filters, highlighting, snippets)।\n\nਜਦੋਂ ਇੱਕ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇਕ ਬੇਨਤੀ ਅਸਲ ਲੋੜ ਬਣ ਜਾਂਦੀ ਹੈ (ਉੱਚ-ਤਰਫ autocomplete ਜਾਂ ਹਰ keystroke 'ਤੇ instant search at scale, ਮਜ਼ਬੂਤ typo tolerance ਅਤੇ spell correction, facets ਅਤੇ aggregations ਨਾਲ ਤੇਜ਼ counts, advanced relevance tooling, ਜਾਂ ਲਗਾਤਾਰ ਉੱਚ ਲੋਡ ਅਤੇ ਵੱਡੇ ਇੰਡੈਕਸ ਜੋ ਰੱਖਣਾ ਮੁਸ਼ਕਿਲ ਹੋਵੇ), ਤਾਂ ਤੁਸੀਂ dedicated search engine ਦੀ ਯੋਜਨਾ ਬਣਾਉ।\n\nਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ app ਸਾਈਡ 'ਤੇ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai (koder.ai) ਇੱਕ ਮਦਦਗਾਰ ਤਰੀਕਾ ਹੋ ਸਕਦਾ ਹੈ search UI ਅਤੇ API ਨੂੰ chat ਰਾਹੀਂ prototype ਕਰਨ ਲਈ, ਫਿਰ snapshots ਅਤੇ rollback ਵਰਤ ਕੇ ਉਹਨਾਂ ਨੂੰ ਮਾਪਦੇ ਹੋਏ iterate ਕਰੋ।ਸਸਤੇ constraints (tenant/status/date) ਪਹਿਲਾਂ filter ਹੁੰਦੇ ਹਨ।ਮਿਲਾਪ @@ ਨਾਲ stored tsvector ਵਿਰੁੱਧ ਹੁੰਦਾ ਹੈ।ਆਰਡਰ ts_rank/ts_rank_cd ਅਤੇ ਇੱਕ stable tie-breaker (ਜਿਵੇਂ updated_at, id) ਨਾਲ ਹੁੰਦਾ ਹੈ।ਇਹ ਨਤੀਜਿਆਂ ਨੂੰ relevant, ਤੇਜ਼ ਅਤੇ pagination ਲਈ stable ਰੱਖਦਾ ਹੈ।
tsvector ਨੂੰ ਉਸੀ ਟੇਬਲ ਤੇ ਰੱਖੋ ਜਿਸਨੂੰ ਤੁਸੀਂ query ਕਰਦੇ ਹੋ।ਉਸ column ਤੇ GIN ਇੰਡੈਕਸ ਬਣਾਓ।ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀ ਕੁਐਰੀ tsvector_column @@ tsquery ਵਰਤ ਰਹੀ ਹੈ।ਅਕਸਰ ਜਦੋਂ ਖੋਜ slows ਹੋਦੀ ਹੈ ਤਾਂ ਇਹ ਹੀ ਸਭ ਤੋਂ ਆਮ ਠੀਕ ਿਹੋਦੀ ਹੈ।
