在postgres中通过查询来提高组的速度

时间:2012-01-30 02:22:47

标签: postgresql indexing sql-order-by database-performance jointable

我有一个具有以下结构的连接表:

CREATE TABLE adjectives_friends
(
  adjective_id integer,
  friend_id integer
)
WITH (
  OIDS=FALSE
);
ALTER TABLE adjectives_friends
  OWNER TO rails;


CREATE UNIQUE INDEX index_adjectives_friends_on_adjective_id_and_friend_id
  ON adjectives_friends
  USING btree
  (adjective_id , friend_id );

CREATE UNIQUE INDEX index_adjectives_friends_on_friend_id_and_adjective_id
  ON adjectives_friends
  USING btree
  (friend_id , adjective_id );
ALTER TABLE adjectives_friends CLUSTER ON index_adjectives_friends_on_friend_id_and_adjective_id;

此表包含约5,000万条记录。

形容词表是约150个条目的查找表。我想做的是找到最接近形容词列表的朋友。假设一个朋友的最大形容词数是10.所以,我尝试了这个查询:

SELECT count(friend_id) count, friend_id
  FROM adjectives_friends
  where adjective_id in (1,2,3,4,5,6,7,8,9,10)
  group by friend_id
  order by count desc
  limit 100

我的开发机器需要大约10秒钟,并带有查询计划

"Limit  (cost=831652.00..831652.25 rows=100 width=4)"
"  ->  Sort  (cost=831652.00..831888.59 rows=94634 width=4)"
"        Sort Key: (count(friend_id))"
"        ->  GroupAggregate  (cost=804185.31..828035.16 rows=94634 width=4)"
"              ->  Sort  (cost=804185.31..811819.81 rows=3053801 width=4)"
"                    Sort Key: friend_id"
"                    ->  Bitmap Heap Scan on adjectives_friends  (cost=85958.72..350003.24 rows=3053801 width=4)"
"                          Recheck Cond: (adjective_id = ANY ('{1,2,3,4,5,6,7,8,9,10}'::integer[]))"
"                          ->  Bitmap Index Scan on index_adjectives_friends_on_adjective_id_and_friend_id  (cost=0.00..85195.26 rows=3053801 width=0)"
"                                Index Cond: (adjective_id = ANY ('{1,2,3,4,5,6,7,8,9,10}'::integer[]))"

顺序是什么杀了我,但我不知道一个避免它的好方法。由于要选择的形容词完全是任意的,因此不能预先计算计数,并且存在> 150选择10种组合。现在,我认为最好的选择是在朋友创建时获得100个最佳结果,保存结果,然后每n个时间间隔更新一次。这是可以接受的,因为预期形容词会经常被切换,而且我没有确切的100个最佳结果。但是,如果我可以将查询速度提高到大约1-2秒,那就不是必要的了。有什么建议吗?

1 个答案:

答案 0 :(得分:1)

我认为你的查询计划不会做得更好。我会接受你的计算,不能预先计算。

我认为你最好的赌注是

如果你可以使用smallint而不是整数,那么你的表和索引会更窄,更适合页面,你的查询应该运行得更快。但smallint是一个2字节的整数,范围从-32768到+32767。如果您需要更多的身份证号码,则smallint将无效。