Otimização de queries PostgreSQL e estratégia de indexação

Otimize a performance do banco de dados PostgreSQL [VERSÃO: 14/15/16] para [NOME DO PROJETO] com as seguintes características:

**Contexto do banco:**
- Tabelas principais: [LISTA COM NÚMERO DE REGISTROS]
- Volume de escrita: [NÚMERO] inserts/updates por hora
- Volume de leitura: [NÚMERO] queries por segundo
- Tamanho total: [VALOR] GB
- Hosting: [RDS/SUPABASE/SELF-HOSTED] com [RAM] de memória

**Queries problemáticas (cole o SQL ou descreva):**
1) [QUERY 1 — ex: busca de produtos com filtros múltiplos]
2) [QUERY 2 — ex: relatório agregado com JOINs]
3) [QUERY 3 — ex: dashboard com contagens em tempo real]

**1) Análise com EXPLAIN ANALYZE:**
- Para cada query, mostre como interpretar o plano de execução
- Identifique: Seq Scans desnecessários, Nested Loops caros, Hash Joins ineficientes
- Custo estimado vs. custo real
- Rows estimadas vs. rows reais (desvio = estatísticas desatualizadas)

**2) Estratégia de Indexação:**
- Índices B-tree para filtros de igualdade e range
- Índices GIN para busca full-text e arrays/JSONB
- Índices parciais (WHERE condição) para queries frequentes
- Índices compostos (ordem das colunas importa)
- Covering indexes (INCLUDE) para evitar table lookups
- Estimativa de tamanho de cada índice
- Trade-off: impacto na escrita vs. ganho na leitura

**3) Refatoração de Queries:**
- CTEs vs. subqueries (materialização no PG 14+)
- Uso de LATERAL JOIN para queries correlacionadas
- Materialized Views para relatórios pesados (refresh strategy)
- Partitioning de tabelas grandes por data
- Connection pooling com PgBouncer

**4) Configuração do PostgreSQL:**
- shared_buffers, work_mem, effective_cache_size
- max_connections vs. connection pooling
- Autovacuum tuning para tabelas com muito UPDATE/DELETE
- pg_stat_statements para monitoramento contínuo

Para cada otimização, estime o ganho de performance esperado (ex: de 4.2s para < 200ms).