Attaching and detaching partitions in PostgreSQL - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When working with partitioned tables, attaching or detaching partitions changes how data is organized.
We want to understand how the time to attach or detach grows as the table or partitions get bigger.
Analyze the time complexity of attaching and detaching partitions in PostgreSQL.
-- Attach a partition
ALTER TABLE parent_table ATTACH PARTITION child_table FOR VALUES FROM (100) TO (200);
-- Detach a partition
ALTER TABLE parent_table DETACH PARTITION child_table;
This code attaches or detaches a child table as a partition of a parent table based on value ranges.
What operations repeat when attaching or detaching partitions?
- Primary operation: Scanning the partition's data to verify constraints (attach) and update metadata.
- How many times: Once per attach or detach command, but the scan (for attach only) depends on the size of the partition's data; detach is O(1).
The time to attach grows with the number of rows in the partition being added; detach is O(1).
| Input Size (rows in partition) | Approx. Operations |
|---|---|
| 10 | Small scan and metadata update |
| 100 | Medium scan and metadata update |
| 1000 | Larger scan and metadata update |
Pattern observation: The work (attach) grows roughly in proportion to the number of rows in the partition.
Time Complexity: O(n) (attach), O(1) (detach)
This means the time to attach a partition grows linearly with the number of rows in that partition; detach is constant time.
[X] Wrong: "Attaching a partition is instant regardless of data size."
[OK] Correct: The system must scan the partition's data to check constraints, so larger partitions take more time to attach (detach is instant).
Understanding how partition operations scale helps you design efficient databases and answer questions about managing large datasets.
"What if we attach multiple small partitions at once? How would the time complexity change?"
Practice
Solution
Step 1: Understand the purpose of attaching partitions
Attaching a partition means linking an existing table to a partitioned table so it becomes one of its parts.Step 2: Clarify what happens to data
The data in the existing table remains intact and is now managed as part of the partitioned table.Final Answer:
It adds an existing table as a part of the partitioned table. -> Option AQuick Check:
Attaching partitions = adding existing table [OK]
- Thinking attaching deletes data
- Confusing attaching with creating new tables
- Assuming attaching merges tables without partitioning
part_2023 to a partitioned table sales in PostgreSQL?Solution
Step 1: Recall the correct syntax for attaching partitions
In PostgreSQL, when attaching an existing partitioned table, the syntax isALTER TABLE sales ATTACH PARTITION part_2023;without specifying the value range, because the partition table already has the range defined.Step 2: Check each option
ALTER TABLE sales ATTACH PARTITION part_2023; uses the correct syntax. ALTER TABLE sales ATTACH PARTITION part_2023 FOR VALUES FROM ('2023-01-01') TO ('2024-01-01'); incorrectly includes the value range, which is only used when creating a new partition, not attaching an existing one. Options C and D use invalid syntax.Final Answer:
ALTER TABLE sales ATTACH PARTITION part_2023; -> Option DQuick Check:
Attach existing partition without value range [OK]
- Including FOR VALUES clause when attaching existing partitions
- Using ADD PARTITION instead of ATTACH PARTITION
- Incorrect keyword order
SELECT count(*) FROM sales; after detaching the partition part_2022?
ALTER TABLE sales DETACH PARTITION part_2022; SELECT count(*) FROM sales;
Solution
Step 1: Understand what detaching a partition does
Detaching removes the partition from the partitioned table but does not delete its data; it becomes a standalone table.Step 2: Effect on queries on the partitioned table
After detaching, queries on the partitioned table no longer include data from the detached partition.Final Answer:
The count excludes rows from part_2022 because it was detached. -> Option CQuick Check:
Detached partitions excluded from parent queries [OK]
- Assuming detaching deletes data
- Thinking detached partitions still count in queries
- Expecting query errors after detach
ALTER TABLE sales DETACH PARTITION part_2023; but get an error saying the partition does not exist. What is the most likely cause?Solution
Step 1: Check if the partition exists and is attached
The error indicatespart_2023is not currently attached tosales, so it cannot be detached.Step 2: Understand the difference between detach and drop
DETACH PARTITIONremoves the link but keeps data;DROP PARTITIONdeletes data. Using drop won't fix a non-attached partition error.Final Answer:
The partition part_2023 is not attached to the sales table. -> Option AQuick Check:
Detach fails if partition not attached [OK]
- Trying to detach partitions not attached
- Confusing DETACH with DROP
- Ignoring if table is partitioned
orders partitioned by range on order_date. You want to archive data from 2020 by detaching the partition orders_2020 and then attaching it to a new partitioned table archived_orders. Which sequence of commands correctly achieves this without data loss?Solution
Step 1: Detach the partition from the original table
UseALTER TABLE orders DETACH PARTITION orders_2020;to remove the partition without deleting data.Step 2: Attach the detached partition to the new partitioned table
UseALTER TABLE archived_orders ATTACH PARTITION orders_2020 FOR VALUES FROM ('2020-01-01') TO ('2021-01-01');to add it as a partition.Final Answer:
Detach from orders, then attach to archived_orders with value range. -> Option BQuick Check:
Detach then attach to new table preserves data [OK]
- Dropping the partition instead of detaching
- Attaching before detaching
- Not specifying value ranges when attaching
