Search configuration and languages in PostgreSQL - Time & Space Complexity
When using search configurations and languages in PostgreSQL, it is important to understand how the search process scales as the amount of data grows.
We want to know how the time to find matches changes when we have more text or more documents to search.
Analyze the time complexity of the following PostgreSQL full-text search query using a specific search configuration.
SELECT *
FROM documents
WHERE to_tsvector('english', content) @@ to_tsquery('english', 'database & search');
This query searches the "content" column of the "documents" table for entries matching the words "database" and "search" using the English search configuration.
Look for repeated work done by the query.
- Primary operation: The database processes each document's text to create a searchable vector and then compares it to the search query.
- How many times: This happens once for each document in the table.
As the number of documents grows, the search work grows roughly in proportion.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 vector creations and comparisons |
| 100 | About 100 vector creations and comparisons |
| 1000 | About 1000 vector creations and comparisons |
Pattern observation: The work grows linearly with the number of documents because each one is checked.
Time Complexity: O(n)
This means the time to complete the search grows directly in proportion to the number of documents being searched.
[X] Wrong: "Using a search configuration makes the search instant no matter how many documents there are."
[OK] Correct: The search configuration helps interpret the text but does not reduce the number of documents to check unless indexes are used.
Understanding how search configurations affect query time helps you explain how databases handle text search efficiently and how to scale searches as data grows.
"What if we add a full-text index on the content column? How would the time complexity change?"
Practice
Solution
Step 1: Understand search configuration role
Search configurations tell PostgreSQL how to handle text for searching, especially for different languages.Step 2: Compare options
Options A, C, and D relate to security, connections, and backups, not text processing.Final Answer:
To define how text is processed for full-text search in a specific language -> Option AQuick Check:
Search configuration = text processing [OK]
- Confusing search configuration with user or connection settings
- Thinking it manages backups or security
- Assuming it stores data instead of processing text
my_config based on the built-in english configuration?Solution
Step 1: Recall correct CREATE syntax
PostgreSQL usesCREATE TEXT SEARCH CONFIGURATION name ( COPY = existing_config )to copy an existing config.Step 2: Check options
Only CREATE TEXT SEARCH CONFIGURATION my_config ( COPY = english ); uses the correct syntax withCOPY = english. Others use invalid keywords.Final Answer:
CREATE TEXT SEARCH CONFIGURATION my_config ( COPY = english ); -> Option CQuick Check:
Use COPY = for cloning configs [OK]
- Using FROM or AS instead of COPY =
- Omitting parentheses around COPY clause
- Confusing syntax with table creation
CREATE TEXT SEARCH CONFIGURATION my_english ( COPY = english );
ALTER TEXT SEARCH CONFIGURATION my_english
ALTER MAPPING FOR asciiword, asciihword, hword_asciipart
WITH simple;
SELECT to_tsvector('my_english', 'PostgreSQL is great!');What is the output of the
SELECT statement?Solution
Step 1: Understand ALTER MAPPING effect
The ALTER MAPPING changes how asciiword and related tokens are processed, using the simple dictionary which does not remove stop words.Step 2: Analyze to_tsvector output
The text 'PostgreSQL is great!' produces tokens: 'PostgreSQL' (pos 1, asciiword) -> 'postgresql':1; 'is' (pos 2, asciiword) -> 'is':2; 'great' (pos 3, asciiword) -> 'great':3. Simple indexes all without dropping stopwords. Matches 'postgresql':1 'great':3 'is':2.Final Answer:
'postgresql':1 'great':3 'is':2 -> Option BQuick Check:
Alter mapping changes dictionary used [OK]
- Assuming stop words are always removed
- Confusing dictionary effects on stemming and stop words
- Expecting syntax error from ALTER MAPPING
ALTER TEXT SEARCH CONFIGURATION my_config ALTER MAPPING FOR word WITH english_stem;
But you get an error:
ERROR: dictionary "english_stem" does not existWhat is the most likely cause?
Solution
Step 1: Analyze error message
The error says the dictionary "english_stem" does not exist, indicating PostgreSQL cannot find that dictionary.Step 2: Identify cause
Most likely, the dictionary name is misspelled or the dictionary was never created in the database.Final Answer:
The dictionary name is misspelled or not created -> Option DQuick Check:
Dictionary must exist before use [OK]
- Assuming ALTER MAPPING is disallowed on configs
- Trying to drop config unnecessarily
- Ignoring dictionary creation step
french configuration but replaces the stopword dictionary with a custom dictionary named my_french_stop. Which sequence of commands correctly achieves this?Solution
Step 1: Create configuration by copying french
UseCREATE TEXT SEARCH CONFIGURATION my_french ( COPY = french );to clone the built-in french config.Step 2: Alter mapping for stopword dictionary
UseALTER MAPPING FOR stopword WITH my_french_stop;to replace the stopword dictionary with the custom one.Final Answer:
CREATE TEXT SEARCH CONFIGURATION my_french ( COPY = french ); ALTER TEXT SEARCH CONFIGURATION my_french ALTER MAPPING FOR stopword WITH my_french_stop; -> Option AQuick Check:
Copy config then alter stopword mapping [OK]
- Using AS instead of COPY = for creation
- Altering wrong token types like word instead of stopword
- Assigning built-in dictionary instead of custom one
Ready to prove it?
Pass the test and this pattern moves unknown
