Si bien no es tan útil para un plan simple como este, http://explain.depesz.com es realmente útil. Consulte http://explain.depesz.com/s/t4fi. Tenga en cuenta la pestaña "estadísticas" y el menú desplegable "opciones".
Cosas a tener en cuenta sobre este plan:
-
El recuento de filas estimado (183) es razonablemente comparable al recuento de filas real (25). No es cientos de veces más, ni es 1. Está más interesado en los órdenes de magnitud cuando se trata de estimaciones de recuento de filas o problemas de "1 frente a no 1". (Ni siquiera necesita precisión "lo suficientemente cerca para el trabajo del gobierno" - "lo suficientemente cerca para la contabilidad de contratación militar" será suficiente). La estimación de selectividad y las estadísticas parecen razonables.
-
Está usando el índice parcial de dos columnas provisto (
index scan using index_cars_onsale_on_brand_and_model_name), por lo que coincide con la condición de índice parcial. Puedes verlo en elFilter: has_auto_gear. También se muestra la condición de búsqueda del índice. -
El rendimiento de la consulta parece razonable dado que el recuento de filas de la tabla significa que el índice es bastante grande, especialmente porque tiene más de dos columnas. Las filas coincidentes estarán dispersas, por lo que es probable que cada fila también requiera una lectura de página separada.
No veo nada malo aquí. Sin embargo, es probable que esta consulta se beneficie en gran medida de los análisis de solo índice de PostgreSQL 9.2.
Es posible que haya un poco de tabla aquí, pero dado el índice de 2 columnas y la gran cantidad de filas, el tiempo de respuesta no es del todo irrazonable, especialmente para una tabla con 170 (!!) columnas que probablemente quepan relativamente pocas tuplas en cada una. página. Si puede permitirse un tiempo de inactividad, intente VACUUM FULL para reorganizar la tabla y reconstruir el índice. Esto bloqueará exclusivamente la mesa durante algún tiempo mientras la reconstruye. Si no puede permitirse el tiempo de inactividad, consulte pg_reorg y/o CREATE INDEX CONCURRENTLY y ALTER INDEX ... RENAME TO .
Puede encontrar EXPLAIN (ANALYZE, BUFFERS, VERBOSE) más informativo a veces, ya que puede mostrar accesos al búfer, etc.
Una opción que puede hacer que esta consulta sea más rápida (aunque corre el riesgo de ralentizar un poco otras consultas) es particionar la tabla en brand y habilite constraint_exclusion . Ver partición.
