Hur fungerar fulltextsökning i PostgreSQL?

Question

Accepted Answer

PostgreSQL har **inbyggd fulltextsökning** — sökning i dokument/text efter ord med stemming, rangering och språkmedvetenhet, långt mer kraftfullt än `LIKE`. Det använder **`tsvector`** (bearbetat dokument) och **`tsquery`** (sökfråga) datatyper, med GIN-index för hastighet.

## Problemet som LIKE inte 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 och 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` konverterar text till normaliserade **lexem** (stammade ord, tar bort stoppord), och `to_tsquery` tolkar sökorden. Operatorn `@@` testar för en träff — så "running" matchar dokument som innehåller "run", "runs", osv.

## En sökbar kolumn + GIN-index (praktisk 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');
```

## Rangering av resultat 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` poängsätter hur väl varje dokument matchar, vilket möjliggör relevansordnade resultat.

## Varför det spelar roll

PostgreSQLs inbyggda fulltextsökning är en värdefull funktion som låter dig implementera **sökfunktionalitet inom din databas** — utan att behöva en separat sökmotor (som Elasticsearch) för många användningsfall — så det är användbart att förstå för applikationer som behöver textsökning.

Huvudvärdet är att det är långt mer kraftfullt än `LIKE` (som inte kan stamma ord, rangera resultat eller indexeras effektivt): fulltextsökning tillhandahåller **ordstamning** (matchar "running" för "run"), **borttagning av stoppord**, **språkmedvetenhet**, **relevansrangering** och är framför allt **indexerbar** (med GIN-index för snabba sökningar) — vilket ger riktiga sökfunktioner (den typ som användare förväntar sig: matchning av ordvariationer, rangering efter relevans) direkt i Postgres.

Att förstå kärnkoncepten — **`tsvector`** (bearbetat, stammad dokumenttext), **`tsquery`** (tolkade söktermer), operatorn **`@@`** för matchning, och **`ts_rank`** för relevansrangering — plus den praktiska setupen (en genererad `tsvector`-kolumn indexerad med GIN för prestanda) täcker hur man implementerar effektiv sökning.

Med dedikerade sökmotorer erbjuds mer för komplexa behov, men PostgreSQL fulltextsökning är tillräcklig och bekväm för många applikationer (undviker driftskomplexiteten hos ett separat söksystem och håller sökdata konsistent med dina relationella data).

Eftersom textsökning är ett vanligt krav för applikationer, och eftersom Postgres tillhandahåller kapabel inbyggd fulltextsökning (kraftfull, indexerbar, med stemming och rangering) som ofta räcker utan en separat sökmotor, är det värdefullt, praktiskt relevant kunskap att förstå den — tsvector/tsquery-modellen, den indexerade setupen och rangering — vilket låter dig lägga till riktiga sökfunktioner med PostgreSQLs inbyggda möjligheter, en användbar funktion som ofta förbises till förmån för mer komplexa externa lösningar när Postgres skulle räcka.