Tienes que averiguar qué WHERE cláusulas que va a usar con esta consulta, con qué frecuencia ocurrirá cada una y qué tan selectiva será cada condición.
-
No indexes las consultas que ocurren con poca frecuencia a menos que tengas que hacerlo.
-
Use índices de varias columnas, comenzando con aquellas columnas que aparecerán en un
=comparación. -
Con respecto al orden de las columnas en un índice multicolumna, comience con aquellas columnas que se usarán en una consulta por sí mismas (un índice puede usarse para una consulta con solo algunas de sus columnas, siempre que estén al principio del índice).
-
Puede omitir columnas con baja selectividad, como
gender.
Por ejemplo, con sus consultas anteriores, si todas son frecuentes y todas las columnas son selectivas, estos índices serían buenos:
... ON apartments (city_id, rooms, size)
... ON apartments (area_id, ad_type, price)
... ON apartments (area_id, ad_type, published_at)
Estos índices también podrían usarse para WHERE cláusulas con solo area_id o city_id en ellos.
Es malo tener demasiados índices.
Si el método anterior generara demasiados índices, p. porque el usuario puede elegir columnas arbitrarias para WHERE cláusula, es mejor indexar columnas individuales u ocasionalmente pares de columnas que regularmente van juntas.
De esa manera, PostgreSQL puede elegir un escaneo de índice de mapa de bits para combinar varios índices para una consulta. Eso es menos eficiente que un análisis de índice normal. , pero generalmente mejor que un análisis secuencial .
