Vous devez déterminer ce WHERE les clauses que vous allez utiliser avec cette requête, la fréquence à laquelle chacune se produira et la sélectivité de chaque condition.
-
N'indexez pas les requêtes qui se produisent rarement, sauf si vous y êtes obligé.
-
Utilisez des index multicolonnes, en commençant par les colonnes qui apparaîtront dans un
=comparaison. -
Concernant l'ordre des colonnes dans un index multicolonne, commencez par les colonnes qui seront utilisées seules dans une requête (un index peut être utilisé pour une requête avec seulement certaines de ses colonnes, à condition qu'elles soient au début de l'index).
-
Vous pouvez omettre les colonnes avec une faible sélectivité, comme
gender.
Par exemple, avec vos requêtes ci-dessus, si elles sont toutes fréquentes et toutes les colonnes sont sélectives, ces index seraient bons :
... ON apartments (city_id, rooms, size)
... ON apartments (area_id, ad_type, price)
... ON apartments (area_id, ad_type, published_at)
Ces index peuvent également être utilisés pour WHERE clauses avec seulement area_id ou city_id en eux.
Il est mauvais d'avoir trop d'index.
Si la méthode ci-dessus conduirait à trop d'index, par ex. car l'utilisateur peut choisir des colonnes arbitraires pour le WHERE clause, il est préférable d'indexer des colonnes individuelles ou occasionnellement des paires de colonnes qui vont régulièrement ensemble.
De cette façon, PostgreSQL peut choisir un balayage d'index bitmap pour combiner plusieurs index pour une requête. C'est moins efficace qu'un balayage d'index classique , mais généralement mieux qu'une analyse séquentielle .
