큰 PostgresSQL 테이블에서 COUNT / GROUP-BY의 성능을 향상 시킵니까?

PostgresSQL 9.2를 실행 중이며 약 6,700,000 행의 12 열 관계가 있습니다. 여기에는 3D 공간에 노드가 포함되어 있으며 각 노드는 사용자를 만든 노드를 참조합니다. 어떤 사용자가 몇 개의 노드를 만들 었는지 쿼리하려면 다음을 수행하십시오 ( explain analyze자세한 내용은 추가).

EXPLAIN ANALYZE SELECT user_id, count(user_id) FROM treenode WHERE project_id=1 GROUP BY user_id;
                                                    QUERY PLAN                                                         
---------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=253668.70..253669.07 rows=37 width=8) (actual time=1747.620..1747.623 rows=38 loops=1)
   ->  Seq Scan on treenode  (cost=0.00..220278.79 rows=6677983 width=8) (actual time=0.019..886.803 rows=6677983 loops=1)
         Filter: (project_id = 1)
 Total runtime: 1747.653 ms

보시다시피, 약 1.7 초가 걸립니다. 데이터 양을 고려하면 그리 나쁘지는 않지만 이것이 개선 될 수 있는지 궁금합니다. 사용자 열에 BTree 색인을 추가하려고 시도했지만 아무런 도움이되지 않았습니다.

다른 제안이 있습니까?

완전성을 위해, 이것은 외래 키 제약 조건, 참조 및 트리거없이 모든 인덱스를 포함한 완전한 테이블 정의입니다.

    Column     |           Type           |                      Modifiers                    
---------------+--------------------------+------------------------------------------------------
 id            | bigint                   | not null default nextval('concept_id_seq'::regclass)
 user_id       | bigint                   | not null
 creation_time | timestamp with time zone | not null default now()
 edition_time  | timestamp with time zone | not null default now()
 project_id    | bigint                   | not null
 location      | double3d                 | not null
 reviewer_id   | integer                  | not null default (-1)
 review_time   | timestamp with time zone |
 editor_id     | integer                  |
 parent_id     | bigint                   |
 radius        | double precision         | not null default 0
 confidence    | integer                  | not null default 5
 skeleton_id   | bigint                   |
Indexes:
    "treenode_pkey" PRIMARY KEY, btree (id)
    "treenode_id_key" UNIQUE CONSTRAINT, btree (id)
    "skeleton_id_treenode_index" btree (skeleton_id)
    "treenode_editor_index" btree (editor_id)
    "treenode_location_x_index" btree (((location).x))
    "treenode_location_y_index" btree (((location).y))
    "treenode_location_z_index" btree (((location).z))
    "treenode_parent_id" btree (parent_id)
    "treenode_user_index" btree (user_id)

편집 : 이것은 @ypercube가 제안한 쿼리 (및 인덱스)를 사용할 때의 결과입니다 (쿼리없이 5.3 초 소요 EXPLAIN ANALYZE).

EXPLAIN ANALYZE SELECT u.id, ( SELECT COUNT(*) FROM treenode AS t WHERE t.project_id=1 AND t.user_id = u.id ) AS number_of_nodes FROM auth_user As u;
                                                                        QUERY PLAN                                                                     
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Seq Scan on auth_user u  (cost=0.00..6987937.85 rows=46 width=4) (actual time=29.934..5556.147 rows=46 loops=1)
   SubPlan 1
     ->  Aggregate  (cost=151911.65..151911.66 rows=1 width=0) (actual time=120.780..120.780 rows=1 loops=46)
           ->  Bitmap Heap Scan on treenode t  (cost=4634.41..151460.44 rows=180486 width=0) (actual time=13.785..114.021 rows=145174 loops=46)
                 Recheck Cond: ((project_id = 1) AND (user_id = u.id))
                 Rows Removed by Index Recheck: 461076
                 ->  Bitmap Index Scan on treenode_user_index  (cost=0.00..4589.29 rows=180486 width=0) (actual time=13.082..13.082 rows=145174 loops=46)
                       Index Cond: ((project_id = 1) AND (user_id = u.id))
 Total runtime: 5556.190 ms
(9 rows)

Time: 5556.804 ms

편집 2 : 이것은 @ erwin-brandstetter가 제안한대로 indexon을 사용 project_id, user_id하지만 스키마 최적화는 아직 사용하지 않은 결과입니다 (쿼리는 원래 쿼리와 같은 속도로 1.5 초 동안 실행됩니다)

EXPLAIN ANALYZE SELECT user_id, count(user_id) as ct FROM treenode WHERE project_id=1 GROUP BY user_id;
                                                        QUERY PLAN                                                      
---------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=253670.88..253671.24 rows=37 width=8) (actual time=1807.334..1807.339 rows=38 loops=1)
   ->  Seq Scan on treenode  (cost=0.00..220280.62 rows=6678050 width=8) (actual time=0.183..893.491 rows=6678050 loops=1)
         Filter: (project_id = 1)
 Total runtime: 1807.368 ms
(4 rows)

주요 문제는 누락 된 인덱스입니다. 그러나 더 있습니다.

SELECT user_id, count(*) AS ct
FROM   treenode
WHERE  project_id = 1
GROUP  BY user_id;

• 많은 bigint열이 있습니다. 아마 과잉입니다. 일반적으로 and와 integer같은 열에는 충분합니다 . 다음 항목에도 도움이됩니다. _{테이블 정의를 최적화하는 동안 데이터 정렬 및 패딩 에 중점을 둔이 관련 답변을 고려하십시오 . 그러나 나머지 부분도 대부분 적용됩니다.}project_iduser_id
  

  • 읽기 성능을 위해 PostgreSQL 구성

• 방에 코끼리 : 더이없는 인덱스project_id . 하나를 만드십시오. 이 답변의 나머지 부분보다 더 중요합니다.
  그것에있는 동안 다중 열 색인을 만드십시오.

  CREATE INDEX treenode_project_id_user_id_index ON treenode (project_id, user_id);

  내 충고를 따랐다면 integer여기에서 완벽 할 것입니다.

  • 복합 색인도 첫 번째 필드의 쿼리에도 적합합니까?

• user_id는 정의 NOT NULL되었으므로 count(user_id)와 동일 count(*)하지만 후자는 약간 짧고 빠릅니다. (이 특정 쿼리에서는 user_id정의 되지 않은 상태에서도 적용 됩니다 NOT NULL.)

• id이미 기본 키이며 추가 UNIQUE제약 조건은 쓸모없는 밸러스트 입니다. 그거 떨어 뜨려:

  "treenode_pkey" PRIMARY KEY, btree (id)
  "treenode_id_key" UNIQUE CONSTRAINT, btree (id)

  _{옆으로 : 나는 id열 이름으로 사용하지 않을 것 입니다. 과 같은 설명을 사용하십시오 treenode_id.}

추가 된 정보

Q : How many different project_id and user_id?
A : not more than five different project_id.

즉, Postgres는 쿼리를 충족시키기 위해 전체 테이블의 약 20 % 를 읽어야 합니다. 인덱스 전용 스캔을 사용할 수 없으면 테이블의 순차적 스캔이 인덱스를 포함하는 것보다 빠릅니다. 테이블 및 서버 설정을 최적화하지 않는 한 더 이상 성능이 향상되지 않습니다.

에 관해서는 인덱스 만 검사 :이 될 수 얼마나 효과적 참조하려면 실행 VACUUM ANALYZE당신은 그 (잠금 테이블을 독점적으로) 줄 수있는 경우에. 그런 다음 쿼리를 다시 시도하십시오. 이제 색인 만 사용 하면 적당히 빨라 집니다. 이 관련 답변을 먼저 읽으십시오.

• ORDER BY 날짜 및 텍스트를 사용하여 간단한 쿼리 최적화

인덱스 전용 스캔에서 Postgres 9.6 및 Postgres Wiki 와 함께 추가 된 매뉴얼 페이지는 물론 입니다.

먼저 색인을 추가 한 (project_id, user_id)다음 9.3 버전 에서이 쿼리를 시도하십시오.

SELECT u.user_id, c.number_of_nodes 
FROM users AS u
   , LATERAL
     ( SELECT COUNT(*) AS number_of_nodes 
       FROM treenode AS t
       WHERE t.project_id = 1 
         AND t.user_id = u.user_id
     ) c 
-- WHERE c.number_of_nodes > 0 ;   -- you probably want this as well
                                   -- to show only relevant users

9.2에서 다음을 시도하십시오.

SELECT u.user_id, 
       ( SELECT COUNT(*) 
         FROM treenode AS t
         WHERE t.project_id = 1 
           AND t.user_id = u.user_id
       ) AS number_of_nodes  
FROM users AS u ;

users테이블 이 있다고 가정 합니다. 그렇지 않은 경우 다음으로 교체하십시오 users.
(SELECT DISTINCT user_id FROM treenode)