2011-05-26 67 views
0

好了,我有以下表(从pgAdmin的信息):在PostgreSQL中比较小的表非常缓慢更新

CREATE TABLE comments_lemms 
(
    comment_id integer, 
    freq integer, 
    lemm_id integer, 
    bm25 real 
) 
WITH (
    OIDS=FALSE 
); 
ALTER TABLE comments_lemms OWNER TO postgres; 

-- Index: comments_lemms_comment_id_idx 

-- DROP INDEX comments_lemms_comment_id_idx; 

CREATE INDEX comments_lemms_comment_id_idx 
    ON comments_lemms 
    USING btree 
    (comment_id); 

-- Index: comments_lemms_lemm_id_idx 

-- DROP INDEX comments_lemms_lemm_id_idx; 

CREATE INDEX comments_lemms_lemm_id_idx 
    ON comments_lemms 
    USING btree 
    (lemm_id); 

还有一表:

CREATE TABLE comments 
(
    id serial NOT NULL, 
    nid integer, 
    userid integer, 
    timest timestamp without time zone, 
    lemm_length integer, 
    CONSTRAINT comments_pkey PRIMARY KEY (id) 
) 
WITH (
    OIDS=FALSE 
); 
ALTER TABLE comments OWNER TO postgres; 

-- Index: comments_id_idx 

-- DROP INDEX comments_id_idx; 

CREATE INDEX comments_id_idx 
    ON comments 
    USING btree 
    (id); 

-- Index: comments_nid_idx 

-- DROP INDEX comments_nid_idx; 

CREATE INDEX comments_nid_idx 
    ON comments 
    USING btree 
    (nid); 

在comments_lemms有800万条目,评论 - 270万。 林执行下面的SQL查询:

update comments_lemms set bm25=(select lemm_length from comments where id=comment_id limit 1) 

而且它需要超过20分钟的运行,而我停下来,因为pgAdmin的看起来像它即将崩溃。 有没有什么办法可以修改这个查询或索引或我的数据库中的任何东西来加速一些事情?我必须在将来运行一些类似的查询,并且等待超过30分钟是相当痛苦的。

+0

当你说“看起来像它即将崩溃?”是什么意思?你有没有理由不加入? Postgres不允许更新连接? – MJB 2011-05-26 11:07:59

+0

Windows开始尖叫,pgAdmin可能停止工作。因为我不知道更新连接,所以在sql中我是一个新手,你会看到:)我使用更新连接重写了我的查询,再次启动它,现在正在等待结果显示。 – Anton 2011-05-26 11:40:18

+0

与问题无关,但我相信'comments_id_idx'没有必要。 Postgres在没有被告知的情况下为PK提供了一个独特的索引。 – 2011-05-29 00:24:20

回答

1

in comments_lemms有800万条目,评论 - 270万。林执行下面的SQL查询:

update comments_lemms set bm25=(select lemm_length from comments where id=comment_id limit 1) 

换句话说,你让经过8M的条目,并为每一行你正在做与索引loopup嵌套循环。由于limit 1指令,PG不会重写/优化它。

试试这个:

update comments_lemms set bm25 = comments.lemm_length 
from comments 
where comments.id = comments_lemms.comment_id; 

应该做两次序列扫描和散列或合并联接在一起,然后一气呵成继续更新。

+0

谢谢,在我发现更新连接之后(感谢上述MJB的评论),我重写了查询的方式与您所做的完全相同。发射并且现在工作20分钟。我甚至在运行查询前对这两个表执行了真空分析。同时从comments_lemms中选择count(*)需要48秒,可以吗?对于8M条目来说, – Anton 2011-05-26 11:46:41

+0

听起来很合理,是的。 :-) – 2011-05-26 11:49:49

+0

哎呀,索引应该可以帮助我加快选择WHERE comment_id in或lemm_id in,他们应该怎么做?你不知道在我的脑海里听起来有多么拼命,因为我必须用这张表制作很多复杂的报告:) – Anton 2011-05-26 11:57:24