PostgreSQL dispose d'une recherche textuelle intégrée — rechercher dans des documents/textes des mots avec racinisation (stemming), classement et reconnaissance de la langue, bien plus puissante que LIKE. Elle utilise les types tsvector (document traité) et tsquery (requête de recherche), avec des index GIN pour la vitesse.
LIKE '%word%' → no stemming (won't match "running" for "run"), no ranking, no language
awareness, and can't use an index well (leading wildcard) → slow and limited.
Full-text search → stems words, ignores stop words, ranks by relevance, indexable.
-- to_tsvector — process text into searchable lexemes (stemmed, stop-words removed)
SELECT to_tsvector('english', 'The cats are running fast');
-- → 'cat':2 'fast':5 'run':4 (stemmed: cats→cat, running→run; "the"/"are" removed)
-- to_tsquery / plainto_tsquery — parse a search query
SELECT to_tsvector('english', body) @@ to_tsquery('english', 'running')
FROM articles; -- @@ = the match operator; matches "run" stem
to_tsvector convertit le texte en lexèmes normalisés (racinise les mots, supprime les mots vides), et to_tsquery analyse les termes de recherche. L'opérateur @@ teste une correspondance — donc « running » correspond aux documents contenant « run », « runs », etc.
-- add a generated tsvector column and index it with GIN
ALTER TABLE articles ADD COLUMN search_vector tsvector
GENERATED ALWAYS AS (to_tsvector('english', title || ' ' || body)) STORED;
CREATE INDEX idx_search ON articles USING GIN (search_vector);
-- fast searches using the index
SELECT title FROM articles
WHERE search_vector @@ plainto_tsquery('english', 'machine learning');
SELECT title, ts_rank(search_vector, query) AS rank
FROM articles, plainto_tsquery('english', 'database') query
WHERE search_vector @@ query
ORDER BY rank DESC; -- most relevant first
ts_rank évalue la pertinence de chaque document, permettant des résultats ordonnés par pertinence.
La recherche textuelle intégrée de PostgreSQL est une fonctionnalité précieuse qui vous permet d'implémenter une fonctionnalité de recherche directement dans votre base de données — sans avoir besoin d'un moteur de recherche distinct (comme Elasticsearch) pour de nombreux cas d'usage — comprendre cette fonctionnalité est donc utile pour les applications nécessitant une recherche textuelle.
La valeur clé est qu'elle est bien plus puissante que LIKE (qui ne peut pas raciniser les mots, classer les résultats, ou être indexée efficacement) : la recherche textuelle complète fournit la racinisation des mots (correspondant « running » pour « run »), la suppression des mots vides, la reconnaissance de la langue, le classement par pertinence, et surtout elle est indexable (avec des index GIN pour des recherches rapides) — offrant de véritables capacités de recherche (le type de recherche que les utilisateurs attendent : correspondance de variations de mots, classement par pertinence) directement dans Postgres.
Comprendre les concepts fondamentaux — tsvector (texte du document traité et racinisé), tsquery (termes de recherche analysés), l'opérateur de correspondance @@, et ts_rank pour le classement par pertinence — plus la configuration pratique (une colonne tsvector générée indexée avec GIN pour la performance) couvre la mise en œuvre d'une recherche efficace.
Bien que les moteurs de recherche dédiés offrent plus pour des besoins complexes, la recherche textuelle de Postgres est suffisante et pratique pour de nombreuses applications (évitant la complexité opérationnelle d'un système de recherche distinct et en gardant les données de recherche cohérentes avec vos données relationnelles).
Comme la recherche textuelle est une exigence d'application courante, et puisque Postgres fournit une recherche textuelle intégrée capable (puissante, indexable, avec racinisation et classement) qui suffit souvent sans moteur de recherche distinct, la comprendre — le modèle tsvector/tsquery, la configuration indexée, et le classement — est une connaissance précieuse et pratiquement pertinente qui vous permet d'ajouter une véritable fonctionnalité de recherche en utilisant les capacités intégrées de PostgreSQL, une fonctionnalité utile qui est souvent négligée en faveur de solutions externes plus complexes alors que Postgres suffirait.