Optimizando una consulta de Postgres con un IN grande

30

Esta consulta obtiene una lista de publicaciones creadas por las personas que sigues. Puede seguir a un número ilimitado de personas, pero la mayoría de las personas siguen a <1000 más.

Con este estilo de consulta, la optimización obvia sería almacenar en caché los "Post"identificadores, pero desafortunadamente no tengo tiempo para eso en este momento.

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;

Rendimientos:

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

¿Cómo se puede optimizar esto por el momento?

Tengo los siguientes índices relevantes:

-- 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;

¿Quizás esto requiere un gran índice compuesto parcial con createdAty userIddónde private IS NULL?

— Garrett
fuente

29

En lugar de usar una lista enorme IN, únete a una VALUESexpresión, o si la lista es lo suficientemente grande, usa una tabla temporal, indexa y luego únete a ella.

Sería bueno si PostgreSQL pudiera hacer esto internamente y automáticamente, pero en este punto el planificador no sabe cómo.

Temas similares:

— Craig Ringer
fuente

28

En realidad, hay dos variantes diferentes de la INconstrucción en Postgres. Uno trabaja con una expresión de subconsulta (que devuelve un conjunto ), el otro con una lista de valores , que es solo una abreviatura de

expression = value1
OR
expression = value2
OR
...

Está utilizando el segundo formulario, que está bien para una lista corta, pero mucho más lento para listas largas. Proporcione su lista de valores como expresión de subconsulta. Recientemente me enteré de esta variante :

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

Me gusta pasar una matriz, desagradable y unirme a ella. Rendimiento similar, pero la sintaxis es más corta:

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

Equivalente siempre que no haya duplicados en el conjunto / matriz proporcionado. De lo contrario, la segunda forma con un JOINdevuelve filas duplicadas, mientras que la primera con INsolo devuelve una sola instancia. Esta sutil diferencia también causa diferentes planes de consulta.

Obviamente, necesitas un índice "Posts"."userId".
Para listas muy largas (miles), vaya con una tabla temporal indexada como @Craig sugirió. Esto permite escaneos de índice de mapa de bits combinados en ambas tablas, que generalmente es más rápido tan pronto como hay múltiples tuplas por página de datos para recuperar del disco.

Relacionado:

¿Cómo usar CUALQUIER lugar en lugar de IN en una cláusula WHERE con Rails?

Aparte: su convención de nomenclatura no es muy útil, hace que su código sea detallado y difícil de leer. En su lugar, use identificadores legales, en minúsculas y sin comillas.

— Erwin Brandstetter
fuente