postgresql 是否应在删除分区之前分离分区?

qfe3c7zg  于 2023-03-08  发布在  PostgreSQL
关注(0)|答案(2)|浏览(280)

我使用的是PostgreSQL 12,其中有一个分区表,这个表有旧的分区需要删除,我看过这样的代码,旧的分区先被分离,然后才被删除:

ALTER TABLE partitioned_table DETACH PARTITION partitioned_table_1;
DROP TABLE partitioned_table_1;

是否有任何理由在删除分区之前分离分区?仅删除分区而不分离是否会影响对数据库的其他查询?

eoigrqb6

eoigrqb61#

手册上的。

  • DROP TABLE partitioned_table_1;表示删除表。ACCESS EXCLUSIVE父表上的锁。
  • ALTER TABLE partitioned_table DETACH PARTITION partitioned_table_1;表示partitioned_table_1仍将存在。ACCESS EXCLUSIVE父表上的锁

分离的分区继续作为独立表存在,但不再与分离它的表有任何联系。
在postgresql 14中,DETACH PARTITION partitioned_table_1 CONCURRENTLYSHARE UPDATE EXCLUSIVE锁定父表。更多信息:https://www.postgresql.org/docs/12/sql-altertable.html
https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-DETACH-PARTITION https://www.postgresql.org/docs/current/ddl-partitioning.html

ctehm74n

ctehm74n2#

这是一个有趣的问题。
让我们参考这个分区表结构(取自PgAnalyze blog post

说到锁定过程,两种类型的操作:

    • 立即删除分区表(立即删除)**
DROP TABLE people_partitioned_birthdays_1800_to_1850;

对比

    • 从根(父)表分离分区表,然后将其删除(detach-drop)**
ALTER TABLE people_partitioned DETACH PARTITION people_partitioned_birthdays_1800_to_1850;
DROP TABLE people_partitioned_birthdays_1800_to_1850;

这两种方法都需要在父表people_partitioned上取一个ACCESS EXCLUSIVE LOCK,当锁处于适当位置时,该ACCESS EXCLUSIVE LOCK阻塞针对people_partitioned的任何SELECT(没有FOR UPDATE/SHARE)语句。
但是,当您需要对分区表执行额外的维护操作时,detach-drop策略确实非常有用。您很可能希望在永久删除该分区之前,使用COPYpg_dump创建该分区的备份,执行数据聚合、分析等操作。由于该分区表已被分离,它将不与父表发生锁冲突。
现在,您可能想知道,您仍然可以执行这些维护操作,而删除分区的时间表仍然存在?

-- perform maintenance action on people_partitioned_birthdays_1800_to_1850 ...
DROP TABLE people_partitioned_birthdays_1800_to_1850;

同样,如果有任何操作需要父表上的排他锁(例如,正在创建/删除另一个新分区,这也需要父表上的排他锁),则上述维护操作将被阻止,直到锁冲突得到解决。
总之,从根分区表中detach-drop分区表通常比immediate-drop更安全。对现有分区表结构的任何操作都不应妨碍对分离分区的维护操作,反之亦然

  • 参考 *

Postgres DDL声明性分区(含用例)

相关问题