我有一个 PostgreSQL 表。select *很慢,但又select id好又快。我认为可能是行的大小非常大并且需要一段时间来运输,或者可能是其他一些因素。
我需要所有字段(或几乎所有字段),因此仅选择一个子集不是一个快速解决方案。选择我想要的字段仍然很慢。
这是我的表架构减去名称:
integer | not null default nextval('core_page_id_seq'::regclass)
character varying(255) | not null
character varying(64) | not null
text | default '{}'::text
character varying(255) |
integer | not null default 0
text | default '{}'::text
text |
timestamp with time zone |
integer |
timestamp with time zone |
integer |
Run Code Online (Sandbox Code Playgroud)
文本字段的大小可以是任意大小。但是,在最坏的情况下,不会超过几千字节。
postgresql performance size disk-space postgresql-performance
我正在通过 Heroku 使用 Postgres 9.3。
我有一个表,“交通”,有 100 万条记录,每天都有很多插入和更新。我需要在不同的时间范围内跨该表执行 SUM 运算,这些调用最多可能需要 40 秒,我很想听听有关如何改进它的建议。
我在这张桌子上有以下索引:
CREATE INDEX idx_traffic_partner_only ON traffic (dt_created) WHERE campaign_id IS NULL AND uuid_self <> uuid_partner;
Run Code Online (Sandbox Code Playgroud)
这是一个示例 SELECT 语句:
SELECT SUM("clicks") AS clicks, SUM("impressions") AS impressions
FROM "traffic"
WHERE "uuid_self" != "uuid_partner"
AND "campaign_id" is NULL
AND "dt_created" >= 'Sun, 29 Mar 2015 00:00:00 +0000'
AND "dt_created" <= 'Mon, 27 Apr 2015 23:59:59 +0000'
Run Code Online (Sandbox Code Playgroud)
这是解释分析:
Aggregate (cost=21625.91..21625.92 rows=1 width=16) (actual time=41804.754..41804.754 rows=1 loops=1)
-> Index Scan using idx_traffic_partner_only on …Run Code Online (Sandbox Code Playgroud) postgresql performance index optimization postgresql-9.3 postgresql-performance
昨晚将我们的数据库从 9.3.5 升级到 9.4.1 后,服务器遇到了高 CPU 峰值。升级是通过 pg_dump 完成的。于是把数据库转成SQL,再导入9.4。
在 CPU 峰值期间,日志中有很多这样的消息:
process X still waiting for ExclusiveLock on extension of relation Y of database Z
after 1036.234 ms
Run Code Online (Sandbox Code Playgroud)
和:
process X acquired ExclusiveLock on extension of relation Y of database Z
after 2788.050 ms
Run Code Online (Sandbox Code Playgroud)
看起来可疑的是,有时在完全相同的毫秒内有几个完全相同的关系号的“获取”消息。
为什么 Postgres 会在同一毫秒内将一个表增长两次?它可能是一个具有高填充因子的索引吗?
欢迎任何有关如何解决此问题的建议。
PS 我也在Postgres 邮件列表上问过这个问题,如果不行,请告诉我。
我在 Postgres 8.2.15 数据库中有一个表。该表膨胀到近 25GB,但在运行完真空和集群后,表的大小显着变小,远低于 1GB。几周后,它又回到了 3.5GB 并且还在攀升。
这不是一个经常删除的表,所以我不知道是什么导致了膨胀。
这仅发生在单个表上。我有一个单独的、结构相同的数据库,为相同的软件提供服务;该数据库中的表没有显示任何膨胀。
有任何想法吗?
postgresql ×4
performance ×2
auto-growth ×1
disk-space ×1
fill-factor ×1
index ×1
locking ×1
optimization ×1
size ×1
vacuum ×1