Drops a specified partition and all its data from a partitioned table. This action is irreversible. Before you run this command, ensure the target partition is no longer needed or has been backed up.
Syntax
ALTER TABLE [schema.]table_name DROP PARTITION partition_name;Parameters
Parameter | Required | Description | Example |
| Yes | The name of the target partitioned table from which to drop a partition. |
|
| Yes | The name of the partition to drop. |
|
Notes
You must be the table owner or a privileged user to run this command.
You cannot drop a table's last partition, because a partitioned table must have at least one.
The
DROP PARTITIONstatement acquires a table-level exclusive lockAccessExclusiveLock. This lock blocks all Data Manipulation Language (DML) and most Data Definition Language (DDL) operations on the table. Run this statement during off-peak hours and allow sufficient time for it to complete to avoid blocking other critical operations on the table.
Examples
FAQ
Q1: Why do I receive a partition "..." of relation "..." does not exist error after running the command?
The partition name does not exist or has a casing mismatch. Partition names are case-sensitive. Query the USER_TAB_PARTITIONS view to confirm the exact partition name, or use double quotation marks ("") for an exact match.
Q2: Why do I receive a permission denied for table ... or must be owner of table ... error?
The current user lacks sufficient permissions. Switch to the table owner or a privileged user to run the command.
Q3: Why do I receive a cannot drop partition due to dependent objects error?
Other database objects, such as foreign key constraints or views, depend on this partition. The default RESTRICT behavior prevents the deletion from being dropped. You must first identify and remove these dependent objects.
Q4: Why is the operation taking a long time or appearing to be stuck?
The DROP PARTITION statement acquires an AccessExclusiveLock. If this lock is blocked by another active, long-running transaction, the operation must wait, which can cause delays or timeouts. You can identify the blocking session by checking for active locks. Then, use the (blocking_pid from that query to find more details about the session with the following statement:
-- Query user information of the blocking thread based on the PID.
SELECT
pid,
usename AS username, -- Database username
application_name, -- Application name (such as JDBC, psql)
client_addr, -- Client IP address
client_hostname, -- Client hostname
client_port, -- Client port
backend_start, -- Time when the connection started
xact_start, -- Time when the transaction started
query_start, -- Time when the current query started
state_change, -- Time when the status last changed
state, -- Status (active, idle, idle in transaction)
wait_event_type, -- Wait event type (such as Lock, IO)
wait_event, -- Specific wait event
query -- Currently running or most recently run SQL statement
FROM
pg_stat_activity
WHERE
pid in 'blocking_pid'; Related SQLs
ALTER TABLE ADD PARTITION: Adds a new partition to a partitioned table.
ALTER TABLE TRUNCATE PARTITION: Clears all data from a partition while keeping the partition definition.
ALTER TABLE SPLIT PARTITION: Splits one partition into two partitions.