Hvordan fungerer fuldtekstsøgning i PostgreSQL?

Question

Accepted Answer

PostgreSQL har **indbygget fuldtekstsøgning** — søgning i dokumenter/tekst efter ord med lemmatisering, rangering og sprogtilgåelse, meget kraftigere end `LIKE`. Den bruger **`tsvector`** (behandlet dokument) og **`tsquery`** (søgeforespørgsel) typer, med GIN-indekser for hastighed.

## Problemet som LIKE ikke løser

```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 og 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` konverterer tekst til normaliserede **leksemer** (lemmatiserer ord, fjerner stoppord), og `to_tsquery` analyserer søgebetingelserne. Operatoren `@@` tester for et match — så "running" matcher dokumenter indeholdende "run," "runs," osv.

## En søgbar kolonne + GIN-indeks (det praktiske opsæt)

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

## Rangering af resultater efter relevans

```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` scorer hvor godt hvert dokument matcher, hvilket gør det muligt at returnere resultat ordnet efter relevans.

## Hvorfor det betyder noget

PostgreSQLs indbyggede fuldtekstsøgning er en værdifuld funktion, der giver dig mulighed for at implementere **søgefunktionalitet inden for din database** — uden at skulle bruge en separat søgemotor (som Elasticsearch) i mange tilfælde — så det er nyttigt at forstå det for applikationer, der har brug for tekstsøgning.

Hovedalien er, at det er meget kraftigere end `LIKE` (som ikke kan lemmatisere ord, rangere resultater eller indekseres effektivt): fuldtekstsøgning giver **ordlemmatisering** (matching af "running" for "run"), **fjernelse af stoppord**, **sprogtilgåelse**, **rangeringsrelevans** og er især **indekserbar** (med GIN-indekser for hurtige søgninger) — og giver rigtige søgefunktioner (den slags som brugere forventer: matching af ordvariationer, rangering efter relevans) direkte i Postgres.

Forståelsen af kernebegreberne — **`tsvector`** (behandlet, lemmatiseret dokumenttekst), **`tsquery`** (analyserede søgebetingelser), matchoperatoren **`@@`**, og **`ts_rank`** for rangeringsrelevans — plus det praktiske opsæt (en genereret `tsvector`-kolonne indekseret med GIN for ydeevne) dækker, hvordan man implementerer effektiv søgning.

Medens dedikerede søgemotorer tilbyder mere til komplekse behov, er Postgres fuldtekstsøgning tilstrækkelig og praktisk for mange applikationer (undgår operationel kompleksitet ved en separat søgesystem og holder søgedata konsistent med dine relationelle data).

Da tekstsøgning er et almindeligt applikationskrav, og da Postgres tilbyder kompetent indbygget fuldtekstsøgning (kraftig, indekserbar, med lemmatisering og rangering), der ofte er tilstrækkelig uden en separat søgemotor, er det at forstå det — tsvector/tsquery-modellen, det indekserede opsæt og rangering — værdifuld, praktisk relevant viden, der giver dig mulighed for at tilføje rigtig søgefunktionalitet ved hjælp af PostgreSQLs indbyggede muligheder, en nyttig funktion, der ofte overses til fordel for mere komplekse eksterne løsninger, når Postgres ville være tilstrækkelig.