Postgres的CREATE UNIQUE INDEX似乎停留了一段时间
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Postgres的CREATE UNIQUE INDEX似乎停留了一段时间相关的知识,希望对你有一定的参考价值。
我像这样在Postgres中创建了一个索引:
CREATE UNIQUE INDEX my_index_name
ON my_table USING btree (custid,
date_trunc('day'::text, timezone('UTC'::text, somedate)),
firstname,
middlename,
lastname);
我监视了可用磁盘空间以获取对索引创建进度的估计,我希望看到可用空间减少,表明该进程正在完成其工作。问题是停机40分钟后,卡住了25分钟,然后又开始消耗磁盘空间:
[当它似乎卡住时,我检查了运行时间长的进程,以查看是否有什么阻塞它(不太可能,这是其他人没有使用的数据库副本),并且我发现有3个相同的“ CREATE INDEX”进程。
这就是我想问的:
- 为什么Postgres显示3个不同的过程?
- 在此期间它似乎卡住了在做什么?
这是我发出的用于查看长时间运行的进程的命令,该进程解开后,只有进程18511继续运行:
my_user => SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
FROM pg_stat_activity
WHERE (now() - query_start) > interval '5 minutes' AND state != 'idle'
ORDER by 2 DESC;
-[ RECORD 1 ]-------------------------------------------------------------------------------------------------------------------------------------------------------------
pid | 18511
duration | 01:04:37.969599
query | CREATE UNIQUE INDEX my_index_name ON my_table USING btree (custid, date_trunc('day'::text, timezone('UTC'::text, somedate)), firstname, middlename, lastname);
state | active
-[ RECORD 2 ]-------------------------------------------------------------------------------------------------------------------------------------------------------------
pid | 12712
duration | 01:04:37.969599
query | CREATE UNIQUE INDEX my_index_name ON my_table USING btree (custid, date_trunc('day'::text, timezone('UTC'::text, somedate)), firstname, middlename, lastname);
state | active
-[ RECORD 3 ]-------------------------------------------------------------------------------------------------------------------------------------------------------------
pid | 12713
duration | 01:04:37.969599
query | CREATE UNIQUE INDEX my_index_name ON my_table USING btree (custid, date_trunc('day'::text, timezone('UTC'::text, somedate)), firstname, middlename, lastname);
state | active
一些其他信息
- 我正在亚马逊的RDS中运行Postgres 11.5
- 此表的大小为255 GiB
- 在该图中,Y轴以MiB为单位,因此顶部有800GiB
答案
如果看到更多创建索引的进程,则说明您拥有PostgreSQL v11或更高版本,并且有并行工作进程在构建索引。这没什么好担心的。它将消耗更多的资源,但是建立索引的速度更快。建立索引有几个步骤:扫描表,对条目进行排序等等。并非所有这些步骤都会消耗磁盘空间。例如,排序不应消耗越来越多的存储空间。
简而言之,一切看起来都应该正确。
以上是关于Postgres的CREATE UNIQUE INDEX似乎停留了一段时间的主要内容,如果未能解决你的问题,请参考以下文章
在从 Postgres 9.4 到 Greenplum 的数据迁移过程中,我应该如何处理我的 UNIQUE 约束
SQL CREATE VIEW 与 for in for 和 SELECTS
postgres 上的 Django unique_together:由 ORM 或 DB 强制执行?
无法混合ecto.create,角色'postgres'不存在[重复]