IN이 큰 Postgres 쿼리 최적화


30

이 검색어는 내가 팔로우 한 사람들이 작성한 게시물 목록을 가져옵니다. 무제한의 사람들을 팔로우 할 수 있지만 대부분의 사람들은 <1000 명을 따릅니다.

이 스타일의 쿼리를 사용하면 "Post"ID 를 캐시하는 것이 분명 최적화 되지만 불행히도 지금은 그럴 시간이 없습니다.

EXPLAIN ANALYZE SELECT
    "Post"."id",
    "Post"."actionId",
    "Post"."commentCount",
    ...
FROM
    "Posts" AS "Post"
INNER JOIN "Users" AS "user" ON "Post"."userId" = "user"."id"
LEFT OUTER JOIN "ActivityLogs" AS "activityLog" ON "Post"."activityLogId" = "activityLog"."id"
LEFT OUTER JOIN "WeightLogs" AS "weightLog" ON "Post"."weightLogId" = "weightLog"."id"
LEFT OUTER JOIN "Workouts" AS "workout" ON "Post"."workoutId" = "workout"."id"
LEFT OUTER JOIN "WorkoutLogs" AS "workoutLog" ON "Post"."workoutLogId" = "workoutLog"."id"
LEFT OUTER JOIN "Workouts" AS "workoutLog.workout" ON "workoutLog"."workoutId" = "workoutLog.workout"."id"
WHERE
"Post"."userId" IN (
    201486,
    1825186,
    998608,
    340844,
    271909,
    308218,
    341986,
    216893,
    1917226,
    ...  -- many more
)
AND "Post"."private" IS NULL
ORDER BY
    "Post"."createdAt" DESC
LIMIT 10;

수율 :

Limit  (cost=3.01..4555.20 rows=10 width=2601) (actual time=7923.011..7973.138 rows=10 loops=1)
  ->  Nested Loop Left Join  (cost=3.01..9019264.02 rows=19813 width=2601) (actual time=7923.010..7973.133 rows=10 loops=1)
        ->  Nested Loop Left Join  (cost=2.58..8935617.96 rows=19813 width=2376) (actual time=7922.995..7973.063 rows=10 loops=1)
              ->  Nested Loop Left Join  (cost=2.15..8821537.89 rows=19813 width=2315) (actual time=7922.984..7961.868 rows=10 loops=1)
                    ->  Nested Loop Left Join  (cost=1.71..8700662.11 rows=19813 width=2090) (actual time=7922.981..7961.846 rows=10 loops=1)
                          ->  Nested Loop Left Join  (cost=1.29..8610743.68 rows=19813 width=2021) (actual time=7922.977..7961.816 rows=10 loops=1)
                                ->  Nested Loop  (cost=0.86..8498351.81 rows=19813 width=1964) (actual time=7922.972..7960.723 rows=10 loops=1)
                                      ->  Index Scan using posts_createdat_public_index on "Posts" "Post"  (cost=0.43..8366309.39 rows=20327 width=261) (actual time=7922.869..7960.509 rows=10 loops=1)
                                            Filter: ("userId" = ANY ('{201486,1825186,998608,340844,271909,308218,341986,216893,1917226, ... many more ...}'::integer[]))
                                            Rows Removed by Filter: 218360
                                      ->  Index Scan using "Users_pkey" on "Users" "user"  (cost=0.43..6.49 rows=1 width=1703) (actual time=0.005..0.006 rows=1 loops=10)
                                            Index Cond: (id = "Post"."userId")
                                ->  Index Scan using "ActivityLogs_pkey" on "ActivityLogs" "activityLog"  (cost=0.43..5.66 rows=1 width=57) (actual time=0.107..0.107 rows=0 loops=10)
                                      Index Cond: ("Post"."activityLogId" = id)
                          ->  Index Scan using "WeightLogs_pkey" on "WeightLogs" "weightLog"  (cost=0.42..4.53 rows=1 width=69) (actual time=0.001..0.001 rows=0 loops=10)
                                Index Cond: ("Post"."weightLogId" = id)
                    ->  Index Scan using "Workouts_pkey" on "Workouts" workout  (cost=0.43..6.09 rows=1 width=225) (actual time=0.001..0.001 rows=0 loops=10)
                          Index Cond: ("Post"."workoutId" = id)
              ->  Index Scan using "WorkoutLogs_pkey" on "WorkoutLogs" "workoutLog"  (cost=0.43..5.75 rows=1 width=61) (actual time=1.118..1.118 rows=0 loops=10)
                    Index Cond: ("Post"."workoutLogId" = id)
        ->  Index Scan using "Workouts_pkey" on "Workouts" "workoutLog.workout"  (cost=0.43..4.21 rows=1 width=225) (actual time=0.004..0.004 rows=0 loops=10)
              Index Cond: ("workoutLog"."workoutId" = id)
Total runtime: 7974.524 ms

당분간 어떻게 이것을 최적화 할 수 있습니까?

다음과 같은 관련 색인이 있습니다.

-- Gets used
CREATE INDEX  "posts_createdat_public_index" ON "public"."Posts" USING btree("createdAt" DESC) WHERE "private" IS null;
-- Don't get used
CREATE INDEX  "posts_userid_fk_index" ON "public"."Posts" USING btree("userId");
CREATE INDEX  "posts_following_index" ON "public"."Posts" USING btree("userId", "createdAt" DESC) WHERE "private" IS null;

아마도 이것은 함께 큰 부분 지수 요구 createdAt및 ?userIdprivate IS NULL

답변:



28

INPostgres 에는 실제로 두 가지 변형이 있습니다. A를 하나 개의 작품 하위 쿼리 식 (돌아 오는 설정을 )하는와 다른 하나는 값 목록 에 딱 속기,

expression = value1
OR
expression = value2
OR
...

짧은 목록에는 적합하지만 긴 목록에 대해서는 속도가 훨씬 느린 두 번째 양식을 사용하고 있습니다. 대신 값 목록을 하위 쿼리 표현식으로 제공하십시오. 나는 최근 에이 변형을 알게되었다 :

WHERE "Post"."userId" IN (VALUES (201486), (1825186), (998608), ... )

나는 배열을 전달하고, 엉망으로 결합하고 싶습니다. 비슷한 성능이지만 구문이 더 짧습니다.

...
FROM   unnest('{201486,1825186,998608, ...}'::int[]) "userId"
JOIN   "Posts" "Post" USING ("userId")

제공된 세트 / 배열에 중복 이없는 한 동일 합니다. 그렇지 않으면 두 번째 폼 JOIN은 중복 행을 반환하고 첫 번째 폼 IN은 단일 인스턴스 만 반환합니다. 이 미묘한 차이로 인해 다른 쿼리 계획도 발생합니다.

분명히에 대한 색인이 필요합니다 "Posts"."userId".
들어 매우 @Craig 제안처럼 긴 목록 (천), 인덱스 임시 테이블과 함께 할 것입니다. 이를 통해 두 테이블에 대해 비트 맵 인덱스를 결합하여 스캔 할 수 있으며, 일반적으로 디스크에서 페치 할 데이터 페이지 당 여러 개의 튜플이있는 즉시 더 빠릅니다.

관련 :

따로 : 명명 규칙은별로 도움이되지 않으며 코드를 자세하고 읽기 어렵게 만듭니다. 대신 소문자로 인용되지 않은 합법적 인 식별자를 사용하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.