PostgreSQL tam metin araması birçok uygulama için yeterli olabilir. Basit bir karar kuralı, başlangıç sorgusu ve indeksleme kontrol listesiyle ne zaman ayrı bir arama motoru eklemeniz gerektiğini öğrenin.
Çoğu kişi “tam metin arama” demez. Hızlı hisseden ve ilk sayfada kullanıcının kastettiğini bulan bir arama kutusu isterler. Sonuçlar yavaş, gürültülü veya garip sıradaysa, kullanıcılar Postgres mi yoksa ayrı bir motor mu kullanıldığıyla ilgilenmez; aramaya güvenmeyi bırakırlar.
Bu tek bir karar: aramayı Postgres içinde tutmak mı, yoksa adanmış bir arama motoru eklemek mi. Hedef mükemmel alaka değildir. Hedef hızlıca yayınlanabilecek, çalıştırması kolay ve uygulamanızın gerçek kullanımına göre yeterince iyi olan sağlam bir temel oluşturmaktır.
Birçok uygulama için PostgreSQL tam metin araması uzun süre yeterlidir. Birkaç metin alanınız (başlık, açıklama, notlar), temel sıralama ve bir iki filtre (durum, kategori, tenant) varsa, Postgres ekstra altyapı olmadan halledebilir. Daha az hareketli parça, daha basit yedeklemeler ve “arama neden kapalı ama uygulama açık?” gibi olayların azalması gibi faydalar elde edersiniz.
“Yeterli” genellikle aynı anda üç hedefi tutturabilmektir:
Somut bir örnek: kullanıcıların projeleri isim ve notlara göre aradığı bir SaaS paneli. “onboarding checklist” gibi bir sorgu doğru projeyi ilk 5 içinde, bir saniyeden kısa sürede getiriyorsa ve sürekli analizörler ayarlamak veya yeniden indeksleme işleriyle uğraşmıyorsanız, bu “yeterli”dir. Bu hedefleri karmaşıklık eklemeden karşılayamıyorsanız, “yerleşik arama vs arama motoru” gerçek bir soru olur.
Ekipler sıklıkla aramayı özellikler olarak tanımlar, sonuçlar olarak değil. Faydalı yaklaşım, her özelliği oluşturmanın, ayarlamanın ve güvenilir tutmanın maliyetine çevirmektir.
Erken istekler genellikle şu şekilde duyulur: yazım hatalarına tolerans, facetler ve filtreler, vurgulamalar, “akıllı” sıralama ve otomatik tamamlama. İlk sürüm için zorunlular ile isteğe bağlıları ayırın. Basit bir arama kutusunun genellikle yapması gerekenler: ilgili öğeleri bulmak, yaygın sözcük formlarını (çoğul, zaman) ele almak, basit filtrelere uymak ve tablo büyüdükçe hızlı kalmaktır. İşte PostgreSQL tam metin aramasının iyi uyduğu yer burasıdır.
Postgres, içeriğiniz normal metin alanlarında duruyorsa ve aramayı veriye yakın tutmak istiyorsanız parlıyor: yardım makaleleri, blog yazıları, destek biletleri, dahili dokümanlar, ürün başlıkları ve açıklamaları veya müşteri kayıtlarındaki notlar. Bunlar çoğunlukla “doğru kaydı bul” problemleridir, “bir arama ürünü inşa et” problemleri değil.
İsteğe bağlı özellikler karmaşıklığı getirir. Yazım toleransı ve zengin otomatik tamamlama genellikle ekstra araçlara yönlendirir. Facetler Postgres’te mümkündür, ama çok sayıda facet, derin analizler ve geniş veri kümelerinde anlık sayımlar istiyorsanız, adanmış bir motor daha çekici görünür.
Gizli maliyet nadiren lisans ücretidir. Asıl maliyet ikinci sistemdir. Bir arama motoru eklediğinizde, veri senkronizasyonu ve backfill (ve bunların yarattığı hatalar), izleme ve yükseltmeler, “arama neden eski veri gösteriyor?” destek işleri ve iki farklı alaka ayarı seti de eklenir.
Emin değilseniz, Postgres ile başlayın, basit bir şey gönderin ve yalnızca belirgin bir gereksinim karşılanamıyorsa başka bir motor ekleyin.
Üç kontorlu bir kural kullanın. Üçünün hepsini geçiyorsanız PostgreSQL tam metin aramasında kalın. Birinde büyük şekilde başarısız olursanız, adanmış bir arama motorunu düşünün.
Alaka ihtiyaçları: “yeterince iyi” sonuçlar kabul edilebilir mi, yoksa yazım hataları, eşanlamlılar, “insanlar ayrıca şunu aradı”, kişiselleştirilmiş sonuçlar gibi birçok kenar durumunda neredeyse mükemmel sıralama mı lazım? Ara sıra kusurlu sıralamayı tolere edebiliyorsanız, Postgres genellikle işe yarar.
Sorgu hacmi ve gecikme: pikte saniyede kaç arama bekliyorsunuz ve gerçek gecikme bütçeniz nedir? Arama trafiği küçük bir dilimse ve uygun indekslerle sorguları hızlı tutabiliyorsanız Postgres yeterlidir. Arama ana iş yükü haline gelip temel okuma/yazmalarla yarışıyorsa, bu bir uyarıdır.
Karmaşıklık: bir veya iki metin alanında mı arama yapıyorsunuz, yoksa birçok sinyali (tagler, filtreler, zaman etkisi, popülerlik, izinler) ve birden çok dili mi birleştiriyorsunuz? Mantık ne kadar karmaşıksa, SQL içinde sürtünme o kadar fazla olur.
Güvenli bir başlangıç: Postgres’te bir temel gönderin, yavaş sorguları ve “sonuç yok” aramalarını loglayın ve yalnızca sonra karar verin. Birçok uygulama asla büyümez ve ikinci bir sistemi çalıştırıp senkronize etme zahmetinden kaçınmış olursunuz.
Genellikle adanmış bir motoru işaret eden kırmızı bayraklar:
Postgres’te kalmak için yeşil bayraklar:
PostgreSQL tam metin araması, metni veritabanının hızlı arayabileceği bir forma dönüştürmenin yerleşik bir yoludur; her satırı taramadan çalışır. İçerikleriniz zaten Postgres’teyse ve tahmin edilebilir operasyonlarla hızlı, yeterli bir arama istiyorsanız en iyi şekilde çalışır.
Bilmeniz gereken üç parça vardır:
ts_rank (veya ts_rank_cd) kullanabilirsiniz.Dil yapılandırması önemlidir çünkü Postgres’in kelimeleri nasıl ele aldığını değiştirir. Doğru konfigürasyonla “running” ve “run” eşleşebilir (stemming) ve ortak dolgu kelimeler göz ardı edilir (stop words). Yanlış konfigürasyonla, normal kullanıcı ifadeleri artık indekslenenle eşleşmediği için arama bozuk hissedebilir.
Önek eşleştirme, insanların “typeahead-benzeri” davranış istediğinde başvurdukları özelliktir; örneğin “dev”i “developer” ile eşleştirmek. Postgres tam metin aramada bu genellikle önek operatörü (term:*) ile yapılır. Algılanan kaliteyi artırabilir, ancak sorgu başına iş yükünü çoğunlukla artırır; bu yüzden varsayılan değil, isteğe bağlı bir yükseltme olarak düşünün.
Postgres’in amaçlamadığı şey: her özellikli eksiksiz bir arama platformu olmak. Eğer bulanık yazım düzeltme, gelişmiş otomatik tamamlama, alan başına karmaşık analizörler, veya birçok düğümde dağıtık indeksleme gibi ihtiyaçlarınız varsa, yerleşik rahat bölgenin dışındasınız. Yine de birçok uygulama için PostgreSQL tam metin araması, kullanıcıların beklediği çoğu şeyi çok daha az hareketli parçayla verir.
İşte aramak istediğiniz içerik için küçük, gerçekçi bir şekil:
-- Minimal example table
CREATE TABLE articles (
id bigserial PRIMARY KEY,
title text NOT NULL,
body text NOT NULL,
updated_at timestamptz NOT NULL DEFAULT now()
);
PostgreSQL tam metin araması için iyi bir temel: kullanıcının yazdığı metinden bir sorgu oluşturun, önce satırları filtreleyin (mümkünse), sonra kalan eşleşmeleri sıralayın.
-- $1 = user search text, $2 = limit, $3 = offset
WITH q AS (
SELECT websearch_to_tsquery('english', $1) AS query
)
SELECT
a.id,
a.title,
a.updated_at,
ts_rank_cd(
setweight(to_tsvector('english', coalesce(a.title, '')), 'A') ||
setweight(to_tsvector('english', coalesce(a.body, '')), 'B'),
q.query
) AS rank
FROM articles a
CROSS JOIN q
WHERE
a.updated_at >= now() - interval '2 years' -- example safe filter
AND (
setweight(to_tsvector('english', coalesce(a.title, '')), 'A') ||
setweight(to_tsvector('english', coalesce(a.body, '')), 'B')
) @@ q.query
ORDER BY rank DESC, a.updated_at DESC, a.id DESC
LIMIT $2 OFFSET $3;
Sonradan işinizi kolaylaştıracak birkaç detay:
WHERE içinde sıralamadan önce koyun (status, tenant_id, tarih aralıkları). Daha az satırı sıralarsınız, dolayısıyla hızlı kalır.ORDER BY için her zaman bir tie-breaker ekleyin (örneğin updated_at, sonra id). Bu, birden çok sonucun aynı rank’e sahip olduğu durumlarda sayfalamanın stabil kalmasını sağlar.websearch_to_tsquery kullanın. Tırnakları ve basit operatörleri insanların beklediği şekilde işler.Bu temel çalıştıktan sonra, to_tsvector(...) ifadesini saklı bir sütuna taşıyın. Bu, her sorguda tekrar hesaplamayı önler ve indekslemeyi basitleştirir.
Çoğu “PostgreSQL tam metin araması yavaş” hikayesi bir şeye dayanır: veritabanı arama dokümanını her sorguda oluşturuyor. Bunu ilk olarak düzeltin: önceden oluşturulmuş bir tsvector saklayın ve onu indeksleyin.
tsvector saklamak: üretilen sütun mu yoksa trigger mı?Arama dokümanınızı aynı satırdaki sütunlardan oluşturuyorsanız, üretilen (generated) sütun en basit seçenektir. Güncellemelerde otomatik doğru kalır ve unutulması zor olur.
Doküman ilişkili tablolara bağlıysa (örneğin bir ürün satırını kategori adıyla birleştirmek) veya tek bir üretilmiş ifadeyle ifade etmek zor bir özel mantık istiyorsanız, trigger ile yönetilen tsvector kullanın. Trigger’lar hareketli parça ekler, bu yüzden küçük tutun ve test edin.
tsvector sütunu üzerinde bir GIN dizini oluşturun. Bu, PostgreSQL tam metin aramasını tipik uygulama aramaları için anlık hissettiren temel kurulumdur.
Birçok uygulama için işe yarayan bir düzen:
tsvectorı en çok aradığınız satırlarla aynı tabloda tutun.tsvector üzerinde GIN dizini ekleyin.tsvectore karşı @@ kullandığından emin olun; to_tsvector(...)i sorguda yeniden hesaplamayın.VACUUM (ANALYZE) düşünün.Vektörü aynı tabloda tutmak genellikle daha hızlı ve daha basittir. Taban tablo çok yazma yoğun ise veya birçok tabloyu kapsayan birleştirilmiş bir dokümanı kendi zamanlamanızla güncellemek istiyorsanız ayrı bir arama tablosu mantıklı olabilir.
Sadece bir alt küme üzerinde arama yapıyorsanız (örneğin status = 'active', çok kiracılı bir uygulamada tek bir tenant veya belirli bir dil), kısmi indeksler (partial indexes) indeks boyutunu azaltır ve aramaları hızlandırabilir; ancak sorgularınız her zaman aynı filtreyi içeriyorsa faydalıdırlar.
Alaka kurallarını basit ve öngörülebilir tutarsanız PostgreSQL tam metin aramasıyla şaşırtıcı derecede iyi sonuçlar alabilirsiniz.
En kolay kazanç alan ağırlıklandırmadır: başlıktaki eşleşmeler gövdedeki eşleşmelerden daha fazla sayılmalıdır. Başlığın gövdeden daha yüksek ağırlıklandırıldığı birleşik bir tsvector oluşturun ve ts_rank veya ts_rank_cd ile sıralayın.
“Taze” veya “popüler” öğeleri yukarı taşımak istiyorsanız dikkatli yapın. Küçük bir takviye iyidir, ama metin alakasının üzerine çıkmasına izin vermeyin. Pratik bir desen: önce metne göre sıralayın, sonra bağları recency ile kırın veya sınırlı bir bonus ekleyin ki alakasız yeni bir öğe mükemmel bir eski eşleşmeyi geçmesin.
Eşanlamlılar ve ifade eşleşmesi beklentilerin sıklıkla ayrıldığı yerlerdir. Eşanlamlılar otomatik değildir; bir tezaurus veya özel sözlük eklemediğiniz sürece gelmezler veya sorgu terimlerini kendiniz genişletmeniz gerekir (örneğin “auth”u “authentication” ile ele almak). İfade eşleşmesi de varsayılan değildir: düz sorgular kelimeleri her yerde eşleştirir, tam “bu ifade” değil. Kullanıcılar tırnak içinde ifadeler yazıyorsa veya uzun sorular giriyorsa, phraseto_tsquery veya websearch_to_tsquery kullanmayı düşünün.
Karışık dil içeriği bir karar gerektirir. Eğer doküman başına dili biliyorsanız, bunu saklayın ve tsvectorı doğru konfigürasyonla üretin (English, Russian vb.). Bilmiyorsanız güvenli bir geri dönüş simple konfigürasyonu ile indekslemek (stemming yok), ya da iki vektör tutmak: bilinen dil için dil-spesifik ve her şey için simple.
Alakayı doğrulamak için küçük ve somut tutun:
Bu genellikle “şablonlar”, “dokümanlar” veya “projeler” gibi uygulama arama kutuları için yeterlidir.
Çoğu “PostgreSQL tam metin araması yavaş ya da alakasız” hikayesi birkaç önlenebilir hatadan kaynaklanır. Bunları düzeltmek genellikle yeni bir arama sistemi eklemekten daha basittir.
Yaygın bir tuzak, tsvectorı kendiliğinden doğru kalan hesaplanmış bir değer gibi kabul etmektir. tsvectorı bir sütunda saklayıp her insert ve update’te güncellemiyorsanız, sonuçlar rastgele görünebilir çünkü indeks artık metinle uyuşmaz. Eğer sorguda to_tsvector(...)i anında hesaplıyorsanız sonuçlar doğru olabilir ama daha yavaştır ve indeksin faydasını kaçırırsınız.
Performansı bozmanın bir diğer kolay yolu, aday kümesini daraltmadan önce sıralama yapmaktır. ts_rank faydalıdır, ama genellikle indeksin eşleşen satırları bulduktan sonra çalıştırılmalıdır. Eğer milyonlarca satır için sıralama yaparsanız (veya önce diğer tablolara join yaparsanız), hızlı bir aramayı tablo taramasına çevirebilirsiniz.
İnsanlar ayrıca “contains” aramasının LIKE '%term%' gibi davranmasını bekler. Öndeki wildcard’lar FTS ile iyi eşleşmez çünkü FTS kelimeler (lexeme) üzerine kuruludur, rastgele alt diziler üzerine değil. Ürün kodları veya kısmi ID’ler için substring arama gerekiyorsa, bu durumda trigram indeksleme gibi farklı bir araç kullanın.
Performans sorunları genellikle eşleşmeden çok sonuç işleme kaynaklıdır. Dikkat edilmesi gereken iki desen:
OFFSET ile sayfalama, Postgres’in sayfalandıkça daha fazla satırı atlamasına neden olur.Operasyonel konular da önemlidir. Çok sayıda güncellemeden sonra indeks bloat oluşabilir ve reindex yapmak pahalı olabilir. Büyük değişikliklerden önce ve sonra gerçek sorgu sürelerini ölçün (EXPLAIN ANALYZE ile). Sayılar olmadan, PostgreSQL tam metin aramasını “düzeltmek” farklı şekilde daha kötü yapmaya açık olursunuz.
PostgreSQL tam metin aramasını suçlamadan önce bu kontrolleri çalıştırın. Çoğu “Postgres arama yavaş ya da alakasız” hatası eksik temellerden kaynaklanır, özellikten değil.
Gerçek bir tsvector oluşturun: onu üretilmiş veya bakımı yapılan bir sütunda saklayın (her sorguda hesaplanmasın), doğru dil konfigürasyonunu kullanın (english, simple vb.) ve alanları karıştırıyorsanız ağırlıklar uygulayın (title > subtitle > body).
İndekse aldıklarınızı normalize edin: gürültülü alanları (ID’ler, boilerplate, navigasyon metni) tsvector dışında tutun ve kullanıcılar nadiren arıyorsa büyük blob’ları kırpın.
Doğru indeksi oluşturun: tsvector sütunu üzerinde GIN indeksi ekleyin ve EXPLAIN içinde kullanıldığını doğrulayın. Eğer sadece bir alt küme aranıyorsa (ör. status = 'published'), kısmi indeks boyutu düşürerek okumaları hızlandırabilir.
Tabloları sağlıklı tutun: sık güncellenen içerikte dead tuple’lar indeks taramalarını yavaşlatabilir. Düzenli vacuum önemli.
Reindex planınız olsun: büyük geçişler veya şişmiş indeksler bazen kontrollü bir reindex penceresi gerektirir.
Veri ve indeks doğru görünce sorgu biçimine odaklanın. PostgreSQL tam metin araması, aday kümesini erken daraltabildiğinde hızlıdır.
Önce filtrele, sonra sırala: sıkı filtreleri (tenant, dil, yayın durumu, kategori) sıralamadan önce uygulayın. Sonra atılacak binlerce satır için sıralama yapmak boşa iştir.
Stabil sıralama kullanın: rank ve sonra updated_at veya id gibi tie-breaker ile sıralayın ki sonuçlar yenilemeler arasında zıplamasın.
“Her şeyi yapan” bir sorgudan kaçının: bulanık eşleştirme veya yazım toleransı gerekiyorsa, bunu kasıtlı yapın (ve ölçün). Ardından istemeden sequential scan’lara yol açmayın.
Gerçek sorguları test edin: en sık yapılan 20 sorguyu toplayın, elle alaka kontrolü yapın ve küçük bir beklenen-sonuç listesi tutarak regresyonları yakalayın.
Yavaş yolları izleyin: yavaş sorguları loglayın, EXPLAIN (ANALYZE, BUFFERS) inceleyin ve indeks boyutu ile cache hit oranını izleyin ki büyüme davranışı değiştirdiğinde fark edebilesiniz.
Bir SaaS yardım merkezi iyi bir başlangıçtır çünkü amaç basittir: kullanıcıların sorularını cevaplayan tek makaleyi bulmalarına yardımcı olmak. Birkaç bin makaleniz var, her birinin başlığı, kısa özeti ve gövde metni var. Ziyaretçilerin çoğu “reset password” veya “billing invoice” gibi 2–5 kelime yazıyor.
PostgreSQL tam metin aramasıyla bu şaşırtıcı derecede hızlı “bitti” hissi verebilir. Birleşik alanlar için tsvector saklarsınız, GIN indeksi eklersiniz ve alaka göre sıralarsınız. Başarı şöyle görünür: sonuçlar 100 ms’nin altında döner, ilk 3 sonuç genellikle doğrudur ve sistemi özel olarak yönetmeniz gerekmez.
Sonra ürün büyür. Destek, ürün alanına, platforma (web, iOS, Android) ve plana (free, pro, business) göre filtreleme ister. Dokümantasyon yazarları eşanlamlılar, “şunu mu demek istediniz” ve yazım hatalarının daha iyi ele alınmasını ister. Pazarlama “sonuçsuz en popüler aramalar” gibi analizler ister. Trafik artar ve arama en yoğun uç noktalarınızdan biri olur.
Bunlar ayrı bir arama motorunun maliyetini haklı çıkarabilecek sinyallerdir:
Pratik bir geçiş yolu: Postgres’i doğruluk kaynağı olarak tutmaya devam edin, arama motoru ekledikten sonra bile. Önce arama sorgularını ve sonuçsuz vakaları loglayın, sonra yalnızca aranabilir alanları yeni indekse kopyalayan asenkron bir senkronizasyon işi çalıştırın. Bir süre her ikisini paralel çalıştırıp kademeli geçiş yapın; her şeyi bir günde riske atmayın.
Eğer aramanız çoğunlukla “bu kelimeleri içeren dokümanları bul” ise ve veri setiniz devasa değilse, PostgreSQL tam metin araması genellikle yeterlidir. Oradan başlayın, çalışır hale getirin ve ayrı bir motor ekleyin sadece eksik özelliği veya ölçek ağrısını isimlendirebildiğinizde.
Elinizde tutmanız gereken özet:
tsvector saklayıp GIN dizini ekleyebiliyorsanız ve sıralama ihtiyaçlarınız temel seviyedeyse Postgres FTS kullanın.Pratik bir sonraki adım: önceki bölümlerdeki başlangıç sorgusunu ve indeks kurulumunu uygulayın, sonra bir hafta boyunca birkaç basit metriği loglayın. p95 sorgu süresini, yavaş sorguları ve basit bir başarı sinyalini izleyin (örneğin “arama -> tıklama -> hemen çıkış yok” gibi bir olay sayacı bile yardımcı olur). Hızla alaka ihtiyacının daha iyi sıralama mı yoksa sadece daha iyi UX (filtreler, vurgulama, daha iyi snippet’ler) mı olduğunu görürsünüz.
Hızlı ilerlemek istiyorsanız, Koder.ai (koder.ai) arayüzü ve API’sini sohbet ile prototiplemek, sonra snapshot ve geri alma kullanarak ölçüm yaparken güvenle yinelemek için kullanışlı olabilir.
PostgreSQL tam metin araması şu üç şeyi aynı anda gerçekleştirebildiğinizde “yeterli”dir:
Eğer bunları saklı tsvector + GIN dizini ile sağlayabiliyorsanız genellikle iyi bir konumdasınız.
Öncelikle PostgreSQL tam metin aramasıyla başlayın. Daha hızlı yayınlarsınız, veriyi ve aramayı aynı yerde tutarsınız ve ayrı bir indeksleme hattı kurup işletmek zorunda kalmazsınız.
Postgres’in iyi bir çözüm olmadığı net bir gereksinim ortaya çıktığında (yüksek kaliteli yazım düzeltme/typo toleransı, zengin otomatik tamamlama, ağır faceting veya arama trafiğinin ana veritabanıyla yarışması) ayrı bir arama motoruna geçin.
Basit bir kural: üç kontrolü de geçiyorsanız Postgres’te kalın:
Eğer bunlardan biri çok kötü başarısız oluyorsa (özellikle yazım/otomatik tamamlama gibi alaka ihtiyaçları ya da yüksek arama trafiği), ayrı bir arama motorunu düşünün.
Postgres FTS’i, aramanın çoğunlukla birkaç alandaki (title/body/notes) “doğru kaydı bul” tipi sorunlar için kullanın; basit filtreler (tenant, status, category) ile iyi çalışır.
Yardım merkezleri, dahili dokümanlar, biletler, blog/makale araması ve kullanıcıların proje isimleri ve notlar ile arama yaptığı SaaS panoları için uygundur.
İyi bir başlangıç sorgusu genellikle şunları yapar:
websearch_to_tsquery ile ayrıştırır.Önceden oluşturulmuş bir tsvector saklayın ve ona GIN dizini ekleyin. Bu, her istekte to_tsvector(...) hesaplamaktan kaçınmanızı sağlar.
Pratik kurulum:
Generated column kullanın eğer arama dokümanı aynı satırdaki sütunlardan oluşturuluyorsa (basit ve kırılması zor).
Arama metni ilişkili tablolara bağlıysa veya tek bir ifade ile ifade etmek zor ise trigger ile yönetilen tsvector kullanın.
Varsayılan tercih: önce generated column, yalnızca gerçekten ihtiyaç olursa trigger kullanın.
Tahmin edilebilir alaka ile başlayın:
Sonra küçük bir gerçek kullanıcı sorguları listesiyle doğrulayın.
Postgres FTS sözcük tabanlıdır, substring tabanlı LIKE '%term%' gibi davranmaz.
Eğer parça arama (ID’ler, kodlar, fragmentler) lazım ise bunu ayrı ele alın (genellikle trigram dizini ile) ve FTS’i bu işe zorlamayın.
Aşağıdaki sinyaller genellikle Postgres FTS’in sınırlarını işaret eder:
Pratik yol: Postgres’i doğruluk kaynağı olarak tutup, gereksinim netleşince asenkron indeksleme eklemek.
tsvector ile @@ eşleştirmesi yapar.ts_rank/ts_rank_cd ve updated_at, id gibi stabil bir tie-breaker ile sıralar.Bu, sonuçları alakalı, hızlı ve sayfalama için kararlı tutar.
tsvector aynı tabloya koyun.tsvector_column @@ tsquery kullandığından emin olun.Bu, arama yavaş olduğunda en sık yapılan düzeltmedir.