Logical replication basics in PostgreSQL - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
Logical replication copies data changes from one database to another in real time.
We want to understand how the work grows as more data changes happen.
Analyze the time complexity of this logical replication setup.
-- Create a publication for all tables
CREATE PUBLICATION my_pub FOR ALL TABLES;
-- Create a subscription to receive changes
CREATE SUBSCRIPTION my_sub CONNECTION 'host=source_db dbname=your_db user=your_user password=your_password' PUBLICATION my_pub;
-- Changes on source tables are sent to subscriber
-- Subscriber applies changes as they arrive
This code sets up logical replication to send all table changes from source to subscriber.
Logical replication repeatedly sends and applies changes.
- Primary operation: Sending each data change (insert, update, delete) from source to subscriber.
- How many times: Once per change event, continuously as changes happen.
As more changes happen, more operations are sent and applied.
| Input Size (number of changes) | Approx. Operations |
|---|---|
| 10 | About 10 send-and-apply steps |
| 100 | About 100 send-and-apply steps |
| 1000 | About 1000 send-and-apply steps |
Pattern observation: The work grows directly with the number of changes.
Time Complexity: O(n)
This means the time to replicate grows in a straight line with the number of changes.
[X] Wrong: "Logical replication sends all data every time, so time grows with table size, not changes."
[OK] Correct: Logical replication only sends new changes, so time depends on how many changes happen, not the total table size.
Understanding how replication time grows helps you design systems that handle data changes efficiently.
"What if we replicated only specific tables instead of all tables? How would the time complexity change?"
Practice
Solution
Step 1: Understand logical replication concept
Logical replication copies only data changes from selected tables, not the entire database.Step 2: Compare options with concept
Encrypting data during transfer, creating a full backup of the database, and optimizing query performance are unrelated to logical replication.Final Answer:
To copy data changes from specific tables between databases -> Option AQuick Check:
Logical replication = Copy data changes [OK]
- Confusing logical replication with physical backup
- Thinking it copies entire database
- Assuming it improves query speed
Solution
Step 1: Identify command for publication creation
The command to create a publication isCREATE PUBLICATIONfollowed by publication name and tables.Step 2: Analyze options
OnlyCREATE PUBLICATION mypub FOR ALL TABLES;creates a publication.CREATE SUBSCRIPTION mysub CONNECTION 'conninfo' PUBLICATION mypub;creates a subscription,CREATE REPLICATION SLOT myslot LOGICAL;creates a replication slot, andCREATE DATABASE mydb WITH REPLICATION;creates a database.Final Answer:
CREATE PUBLICATION mypub FOR ALL TABLES; -> Option CQuick Check:
Publication creation = CREATE PUBLICATION [OK]
- Mixing publication and subscription commands
- Using replication slot command for publication
- Confusing database creation with replication setup
CREATE PUBLICATION mypub FOR TABLE customers;And on the subscriber:
CREATE SUBSCRIPTION mysub CONNECTION 'host=source dbname=mydb user=replicator password=secret' PUBLICATION mypub;What will happen when a new row is inserted into the
customers table on the publisher?Solution
Step 1: Understand publication and subscription setup
The publication includes the customers table, and the subscription connects to it, enabling replication of changes.Step 2: Analyze effect of insert on replication
Inserts on the published table are sent to the subscriber, so the new row will appear there.Final Answer:
The new row will be replicated to the subscriber's customers table -> Option AQuick Check:
Insert on published table = replicated row [OK]
- Thinking subscription is missing when it is created
- Assuming full table copy on each insert
- Believing inserts are not replicated
Solution
Step 1: Check publication includes tables
If the publication does not include the desired tables, no changes will be sent to the subscriber.Step 2: Evaluate other options
The subscriber database is offline is unlikely because subscription requires the subscriber to be online. Logical replication does not support inserts is false; inserts are supported. You forgot to create a replication slot on the subscriber is incorrect because replication slots are created on the publisher, not subscriber.Final Answer:
The publication does not include the tables you want to replicate -> Option DQuick Check:
Missing tables in publication = no replication [OK]
- Confusing replication slot location
- Assuming inserts are unsupported
- Ignoring publication table list
orders table but exclude the order_logs table, which is large and not needed on the subscriber. How should you set up the publication?Solution
Step 1: Understand selective table replication
To replicate only the orders table, the publication must include only that table.Step 2: Analyze options for correct table inclusion
CREATE PUBLICATION mypub FOR ALL TABLES; replicates all tables, including order_logs which is unwanted. CREATE PUBLICATION mypub FOR TABLE orders, order_logs; includes both tables. CREATE PUBLICATION mypub FOR TABLE order_logs; includes only order_logs, which is unwanted.Final Answer:
CREATE PUBLICATION mypub FOR TABLE orders; -> Option BQuick Check:
Include only needed tables in publication [OK]
- Using FOR ALL TABLES when exclusion is needed
- Including unwanted tables in publication
- Confusing publication and subscription roles
