AFTER trigger behavior in PostgreSQL - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When using AFTER triggers in PostgreSQL, it's important to know how the time to run the trigger grows as the number of affected rows increases.
We want to understand how the trigger's execution time changes when more rows are inserted, updated, or deleted.
Analyze the time complexity of this AFTER trigger example.
CREATE FUNCTION log_update() RETURNS trigger AS $$
BEGIN
INSERT INTO audit_log(table_name, changed_at) VALUES (TG_TABLE_NAME, now());
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER after_update_trigger
AFTER UPDATE ON my_table
FOR EACH ROW EXECUTE FUNCTION log_update();
This trigger runs after each row update and inserts a log record for that row.
Look at what repeats when the trigger runs.
- Primary operation: The trigger function runs once for every updated row.
- How many times: Equal to the number of rows updated in the statement.
As more rows are updated, the trigger runs more times.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 trigger executions |
| 100 | 100 trigger executions |
| 1000 | 1000 trigger executions |
Pattern observation: The number of trigger executions grows directly with the number of rows updated.
Time Complexity: O(n)
This means the total time to run the trigger grows linearly with the number of rows affected.
[X] Wrong: "The trigger runs only once no matter how many rows are updated."
[OK] Correct: AFTER triggers defined FOR EACH ROW run once per row, so more rows mean more trigger executions.
Understanding how triggers scale with data changes helps you write efficient database logic and explain performance impacts clearly.
"What if the trigger was defined FOR EACH STATEMENT instead of FOR EACH ROW? How would the time complexity change?"
Practice
AFTER trigger in PostgreSQL?Solution
Step 1: Understand the timing of AFTER triggers
AFTER triggers run only after the main database action (INSERT, UPDATE, DELETE) has completed successfully.Step 2: Identify the purpose of AFTER triggers
They are used to perform actions like logging or notifications after the main operation finishes.Final Answer:
To execute a function after the main database operation completes successfully -> Option AQuick Check:
AFTER trigger = runs after operation [OK]
- Confusing AFTER with BEFORE triggers
- Thinking AFTER triggers can stop the main operation
- Assuming AFTER triggers run before the operation
Solution
Step 1: Recall the correct CREATE TRIGGER syntax
PostgreSQL requires specifying FOR EACH ROW or FOR EACH STATEMENT for triggers.Step 2: Identify the correct syntax for AFTER INSERT
CREATE TRIGGER trg AFTER INSERT ON table_name FOR EACH ROW EXECUTE FUNCTION func_name(); correctly uses AFTER INSERT ON table_name FOR EACH ROW EXECUTE FUNCTION func_name();Final Answer:
CREATE TRIGGER trg AFTER INSERT ON table_name FOR EACH ROW EXECUTE FUNCTION func_name(); -> Option AQuick Check:
AFTER INSERT + FOR EACH ROW + EXECUTE FUNCTION = CREATE TRIGGER trg AFTER INSERT ON table_name FOR EACH ROW EXECUTE FUNCTION func_name(); [OK]
- Omitting FOR EACH ROW or FOR EACH STATEMENT
- Using BEFORE instead of AFTER
- Using EXECUTE PROCEDURE instead of EXECUTE FUNCTION in modern PostgreSQL
CREATE TABLE users(id SERIAL PRIMARY KEY, name TEXT);
CREATE FUNCTION log_insert() RETURNS trigger AS $$
BEGIN
RAISE NOTICE 'Inserted user: %', NEW.name;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER after_user_insert AFTER INSERT ON users FOR EACH ROW EXECUTE FUNCTION log_insert();
INSERT INTO users(name) VALUES ('Alice');Solution
Step 1: Understand the trigger function behavior
The function raises a NOTICE with the inserted user's name after insert.Step 2: Recognize AFTER trigger effects
AFTER triggers run after the insert, so the notice will be shown, and the insert completes successfully.Final Answer:
A notice message: 'Inserted user: Alice' -> Option DQuick Check:
AFTER trigger raises notice = A notice message: 'Inserted user: Alice' [OK]
- Thinking RETURN NEW is invalid in AFTER triggers
- Expecting no output from the trigger
- Assuming the insert is rolled back
Solution
Step 1: Understand when AFTER UPDATE triggers fire
AFTER UPDATE triggers fire only if the UPDATE actually changes data.Step 2: Analyze the cause of no trigger firing
If the UPDATE sets columns to their existing values, no actual change occurs, so the trigger does not fire.Final Answer:
The UPDATE statement does not change any column values -> Option BQuick Check:
UPDATE with no change = no AFTER trigger fire [OK]
- Assuming triggers fire even if no data changes
- Confusing BEFORE and AFTER triggers
- Not matching trigger function with trigger type
Solution
Step 1: Understand the requirement for conditional logging after delete
We want to log only after the delete happens and only for rows with status 'active'.Step 2: Choose the correct trigger timing and condition
AFTER DELETE trigger can access OLD row data and conditionally log if OLD.status = 'active'.Final Answer:
Create an AFTER DELETE trigger that checks if OLD.status = 'active' inside the trigger function before logging -> Option CQuick Check:
Conditional logging after delete = AFTER trigger with check [OK]
- Using BEFORE trigger which runs before deletion
- Logging all deletes without condition
- Trying to prevent deletion instead of logging
