¿Hay alguna manera de averiguar cuál es la mejor manera de saber qué índices crear para una tabla?

Breves reglas generales. (Algunos de estos se crean automáticamente, pero posiblemente se pueden eliminar manualmente más tarde, dependiendo de sus dbms. No asuma que siempre trabajará en PostgreSQL).

• Indice cada clave primaria.
• Indice cada clave externa.
• Indice cada columna utilizada en una cláusula JOIN.
• Indice cada columna utilizada en una cláusula WHERE.
• Estudie su documentación para conocer las opciones de indexación "esotéricas" que admite dbms.

Cada clave principal significa que las claves primarias de varias columnas deben tener un único índice que cubra todas las columnas. PostgreSQL creará este índice automáticamente si declara una clave primaria de varias columnas.

Hay muchos casos en los que un solo índice de varias columnas le ofrece un mejor rendimiento que varios índices de una sola columna. Monitoree las consultas lentas y realice pruebas para determinar cuál es cuál.

Suponga que cualquier cambio en la indexación mejorará algunas actividades de la base de datos y degradará otras. Me resulta útil tener un conjunto de sentencias SQL que pueda perfilar antes y después de realizar cambios en los índices. Este conjunto incluye instrucciones SELECT, INSERT, UPDATE y DELETE.

No hay sustituto para estudiar los documentos para sus dbms particulares.

• CREAR ÍNDICE
• Índices (Observe especialmente las secciones sobre expresiones de indexación, índices parciales y sobre el uso del índice)

Además de lo que @Catcall ya proporcionó , y para agregar un pequeño correctivo:

También cubrí algunos conceptos básicos en esta respuesta estrechamente relacionada en SO recientemente .

Las respuestas hasta ahora parecen indicar que necesita crear índices en las claves primarias, pero ese no es el caso en PostgreSQL (se aplican excepciones parciales). Cito el manual aquí :

PostgreSQL crea automáticamente un índice único cuando se define una restricción única o clave primaria para una tabla. El índice cubre las columnas que conforman la clave primaria o la restricción única (un índice de varias columnas , si corresponde), y es el mecanismo que impone la restricción.

El énfasis en negrita es mío.

Es posible que desee crear índices adicionales para las columnas segunda o posterior de un índice de varias columnas, pero la primera generalmente está bien cubierta por un índice de varias columnas, excepto cuando las columnas adicionales hacen que el índice sea mucho más grande. Discutimos eso en gran detalle bajo esta pregunta relacionada:

¿Un índice compuesto también es bueno para consultas en el primer campo?

Los índices de varias columnas , los índices parciales y los índices en expresiones son herramientas particularmente poderosas en PostgreSQL. Desde PostgreSQL 9.2 también hay escaneos de solo índice , el equivalente a "cubrir índices" en otros RDBMS. Este no es otro tipo de índice, sino una nueva capacidad del RDBMS con los tipos de índice existentes.

Cada índice conlleva costos específicos , por lo que no hay forma de evitar algunos conocimientos básicos para optimizar realmente la indexación. Solo crear más índices puede hacer más daño que bien. En particular, los índices pueden evitar que las actualizaciones HOT mejoren el rendimiento.

En general, las operaciones de escritura ( DELETE, UPDATE) se vuelven más caras (¡pero también pueden beneficiarse!), Mientras que las operaciones de lectura ( SELECT) generalmente solo se benefician. Demasiados índices pueden agotar la memoria caché para que incluso las operaciones de lectura puedan verse afectadas.

Finalmente, esta página Wiki de Postgres sobre mantenimiento de índices presenta herramientas para encontrar índices duplicados o no utilizados (entre otras cosas).

Hay dos opciones

1. Hazlo tu.
2. La tecnología lo hace.

La respuesta para hacerlo usted mismo está bastante exhaustivamente documentada aquí. Así que veamos algo más.

Pghero

Pghero puede ayudarte si quieres un consejo automatizado.

Dicho esto, tiene algunas deficiencias.

1. Solo funciona WHEREy ORDER BY, no JOINS.
2. Solo usa estadísticas sobre el porcentaje NULL y valores distintos.

Mira este video para más información .