Ottimizzazione di una query Postgres con un IN di grandi dimensioni

30

Questa query ottiene un elenco di post creati dalle persone che segui. Puoi seguire un numero illimitato di persone, ma la maggior parte delle persone ne segue <1000.

Con questo stile di query, l'ovvia ottimizzazione sarebbe quella di memorizzare nella cache gli "Post"ID, ma sfortunatamente non ho il tempo per farlo in questo 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;

I rendimenti:

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

Come può essere ottimizzato per il momento?

Ho i seguenti indici rilevanti:

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

Forse questo richiede un grande indice composito parziale con createdAte userIddove private IS NULL?

— Garrett
fonte

29

Invece di usare una lista enorme IN, unisciti a VALUESun'espressione o, se la lista è abbastanza grande, usa una tabella temporanea, indicizzala e poi unisciti su di essa.

Sarebbe bello se PostgreSQL potesse farlo internamente e automaticamente, ma a questo punto il planner non sa come fare.

Argomenti simili:

— Craig Ringer
fonte

28

In INPostgres ci sono in realtà due diverse varianti del costrutto. Uno funziona con un'espressione di subquery (che restituisce un set ), l'altro con un elenco di valori , che è solo una scorciatoia per

expression = value1
OR
expression = value2
OR
...

Stai usando il secondo modulo, che va bene per un breve elenco, ma molto più lento per quelli lunghi. Fornisci invece il tuo elenco di valori come espressione di subquery. Sono stato recentemente informato di questa variante :

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

Mi piace passare un array, unest e unirmi ad esso. Prestazioni simili, ma la sintassi è più breve:

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

Equivalente se non ci sono duplicati nel set / array fornito. Else il secondo modulo con un JOINrestituisce righe duplicate, mentre il primo con INrestituisce solo una singola istanza. Questa sottile differenza provoca anche piani di query diversi.

Ovviamente, hai bisogno di un indice su "Posts"."userId".
Per elenchi molto lunghi (migliaia), vai con una tabella temporanea indicizzata come suggerito da @Craig. Ciò consente scansioni dell'indice bitmap combinato su entrambe le tabelle, che in genere è più veloce non appena ci sono più tuple per pagina di dati da recuperare dal disco.

Relazionato:

Come usare QUALSIASI invece di IN in una clausola WHERE con Rails?

A parte: la tua convenzione di denominazione non è molto utile, rende il tuo codice dettagliato e difficile da leggere. Utilizzare piuttosto identificatori legali, minuscoli e non quotati.

— Erwin Brandstetter
fonte