Reformatage de votre plan de requête pour plus de clarté :
QUERY PLAN Aggregate (cost=126377.96..126377.97 rows=1 width=0)
-> Hash Join (cost=6014.51..126225.38 rows=61033 width=0)
Hash Cond: (contacts_lists.contact_id = plain_contacts.contact_id)
-> Hash Join (cost=3067.30..121828.63 rows=61033 width=8)
Hash Cond: (contacts_lists.contact_id = contacts.id)
-> Index Scan using index_contacts_lists_on_list_id_and_contact_id
on contacts_lists (cost=0.00..116909.97 rows=61033 width=4)
Index Cond: (list_id = 66996)
-> Hash (cost=1721.41..1721.41 rows=84551 width=4)
-> Seq Scan on contacts (cost=0.00..1721.41 rows=84551 width=4)
Filter: ((NOT email_bad) AND (NOT email_unsub))
-> Hash (cost=2474.97..2474.97 rows=37779 width=4)
-> Seq Scan on plain_contacts (cost=0.00..2474.97 rows=37779 width=4)
Filter: has_email
Deux index partiels pourraient éliminez les analyses séquentielles en fonction de la distribution de vos données :
-- if many contacts have bad emails or are unsubscribed:
CREATE INDEX contacts_valid_email_idx ON contacts (id)
WHERE (NOT email_bad AND NOT email_unsub);
-- if many contacts have no email:
CREATE INDEX plain_contacts_valid_email_idx ON plain_contacts (id)
WHERE (has_email);
Il se peut qu'il manque un index sur une clé étrangère :
CREATE INDEX plain_contacts_contact_id_idx ON plain_contacts (contact_id);
Enfin, si vous n'avez jamais analysé vos données, vous devez exécuter :
VACUUM ANALYZE;
Si c'est encore lent une fois que tout cela est fait, vous ne pouvez pas faire grand-chose à part fusionner vos tables plain_contacts et vos tables de contacts :obtenir le plan de requête ci-dessus malgré les index ci-dessus signifie que la plupart/tous vos abonnés y sont abonnés liste particulière - auquel cas le plan de requête ci-dessus est le plus rapide que vous obtiendrez.
