Hoe werkt full-text search in PostgreSQL?

Question

Accepted Answer

PostgreSQL heeft **ingebouwde full-text search** — het doorzoeken van documenten/tekst naar woorden met stemming, ranking en taalondersteunin, veel krachtiger dan `LIKE`. Het gebruikt **`tsvector`** (verwerkt document) en **`tsquery`** (zoekquery) types, met GIN indexes voor snelheid.

## Het probleem dat LIKE niet oplost

```text
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.
```

## tsvector en tsquery

```sql
-- 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` converteert tekst naar genormaliseerde **lexemes** (stemt woorden, verwijdert stop words), en `to_tsquery` parseert de zoektermen. De `@@` operator test op een match — dus "running" matcht documenten met "run", "runs", enz.

## Een doorzoekbare kolom + GIN index (de praktische setup)

```sql
-- 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');
```

## Resultaten ranken op relevantie

```sql
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` scoort hoe goed elk document overeenkomt, wat relevantie-geordende resultaten mogelijk maakt.

## Waarom het belangrijk is

PostgreSQL's ingebouwde full-text search is een waardevolle functie waarmee u **zoekfunctionaliteit binnen uw database** kunt implementeren — zonder dat u voor veel use cases een aparte zoekmachine nodig hebt (zoals Elasticsearch) — dus het begrijpen ervan is nuttig voor applicaties die tekstzoeking nodig hebben.

De kernwaarde is dat het veel krachtiger is dan `LIKE` (wat geen woorden kan stemmen, resultaten ranken, of efficiënt indexeren): full-text search biedt **word stemming** ("running" matchen voor "run"), **stop-word verwijdering**, **taalondersteunin**, **relevantie ranking**, en is cruciaal **indexeerbaar** (met GIN indexes voor snelle zoekopdrachten) — waardoor echte zoekmogelijkheden (het soort dat gebruikers verwachten: woordvariaties matchen, ranken op relevantie) rechtstreeks in Postgres geleverd worden.

Het begrijpen van de kernconcepten — **`tsvector`** (verwerkte, gestemmde documenttekst), **`tsquery`** (geparste zoektermen), de **`@@`** match operator, en **`ts_rank`** voor relevantie ranking — plus de praktische setup (een gegenereerde `tsvector` kolom geïndexeerd met GIN voor prestaties) dekt in hoe u effectieve zoeking implementeert.

Hoewel dedicated zoekmachines meer bieden voor complexe behoeften, is Postgres full-text search voldoende en handig voor veel applicaties (waarmee u de operationele complexiteit van een apart zoeksysteem voorkomt en zoekopdrachten consistent houdt met uw relationele gegevens).

Omdat tekstzoeking een veelvoorkomende applicatievereiste is, en omdat Postgres capabele ingebouwde full-text search biedt (krachtig, indexeerbaar, met stemming en ranking) die vaak volstaat zonder een aparte zoekmachine, is het begrijpen ervan — het tsvector/tsquery model, de geïndexeerde setup, en ranking — waardevolle, praktisch relevante kennis waarmee u echte zoekfunctionaliteit kunt toevoegen met PostgreSQL's ingebouwde mogelijkheden, een nuttige functie die vaak over het hoofd wordt gezien ten voordele van complexere externe oplossingen wanneer Postgres volstaat.