Why full-text search matters in PostgreSQL - Performance Analysis
When searching text in a large database, how fast the search runs is very important.
We want to know how the search time changes as the amount of text grows.
Analyze the time complexity of the following full-text search query.
SELECT * FROM documents
WHERE to_tsvector('english', content) @@ to_tsquery('english', 'database & search');
This query finds all documents containing words related to "database" and "search" using full-text search.
Look for repeated work done by the query.
- Primary operation: Checking each document's text vector against the search query.
- How many times: Once per document in the table.
As the number of documents grows, the search work grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 checks |
| 100 | 100 checks |
| 1000 | 1000 checks |
Pattern observation: The work grows directly with the number of documents.
Time Complexity: O(n)
This means the search time grows in a straight line as more documents are added.
[X] Wrong: "Full-text search always runs instantly no matter how much data there is."
[OK] Correct: The search still checks many documents, so more data means more work unless indexes are used.
Understanding how search time grows helps you explain how databases handle big text data efficiently.
"What if we add a full-text index on the content column? How would the time complexity change?"
Practice
Solution
Step 1: Understand full-text search purpose
Full-text search is designed to quickly find words or phrases inside large text fields.Step 2: Compare options to purpose
Only It allows fast searching of words inside large text columns. describes this purpose correctly; others describe unrelated features.Final Answer:
It allows fast searching of words inside large text columns. -> Option BQuick Check:
Full-text search = fast word search [OK]
- Confusing full-text search with spell check
- Thinking it encrypts data
- Assuming it handles backups
Solution
Step 1: Identify function for text vector conversion
to_tsvector converts text into a searchable document vector; it requires a configuration like 'english'.Step 2: Check syntax correctness
SELECT to_tsvector('english', column_name) FROM table_name; uses to_tsvector with language and column, which is correct syntax.Final Answer:
SELECT to_tsvector('english', column_name) FROM table_name; -> Option AQuick Check:
to_tsvector needs language + text [OK]
- Using to_tsquery instead of to_tsvector for conversion
- Omitting language configuration
- Passing wrong argument order
articles with a column content, what will this query return?SELECT id FROM articles WHERE to_tsvector('english', content) @@ to_tsquery('english', 'database & search');Solution
Step 1: Understand the @@ operator
The @@ operator checks if the text vector matches the text query.Step 2: Interpret the query string 'database & search'
The '&' means AND, so both words must be present in the content.Final Answer:
All article IDs where content contains both 'database' and 'search'. -> Option DQuick Check:
'&' means AND in to_tsquery [OK]
- Thinking '&' means OR
- Assuming phrase match instead of word match
- Believing query causes syntax error
SELECT * FROM emails WHERE to_tsvector('english', body) @@ to_tsquery('english', 'urgent | meeting');What is the most likely reason?
Solution
Step 1: Understand the query logic
The '|' operator means OR, so it matches rows containing 'urgent' or 'meeting'.Step 2: Analyze why no rows return
If no rows match, likely none contain these words in the body column.Final Answer:
The query searches for 'urgent' OR 'meeting', but none exist in body. -> Option CQuick Check:
'|' means OR; no matches means words missing [OK]
- Thinking '|' is invalid syntax
- Assuming to_tsvector can't be used on text
- Ignoring possibility of no matching data
Solution
Step 1: Understand operator precedence in to_tsquery
AND (&) has higher precedence than OR (|), so parentheses are needed to group OR terms.Step 2: Analyze each option
SELECT id FROM articles WHERE to_tsvector('english', content) @@ to_tsquery('english', '(database | search) & !slow'); correctly groups 'database | search' together, then AND NOT 'slow'. Others either miss grouping or change logic.Final Answer:
SELECT id FROM articles WHERE to_tsvector('english', content) @@ to_tsquery('english', '(database | search) & !slow'); -> Option AQuick Check:
Use parentheses to group OR before AND NOT [OK]
- Missing parentheses causing wrong logic
- Using AND instead of OR for 'database' or 'search'
- Placing NOT operator incorrectly
Ready to prove it?
Pass the test and this pattern moves unknown
