Cómo optimizar la consulta postgres

Prueba esta versión reescrita:

SELECT fat.*   
FROM   Table1 fat
JOIN   conciliacao_vendas cv USING (empresa_id, chavefato, rede_id)
JOIN   loja lj               ON lj.id = fat.loja_id  
JOIN   rede rd               ON rd.id = fat.rede_id  
JOIN   bandeira bd           ON bd.id = fat.bandeira_id  
JOIN   produto pd            ON pd.id = fat.produto_id  
JOIN   loja_extensao le      ON le.id = fat.loja_extensao_id  
JOIN   conta ct              ON ct.id = fat.conta_id
JOIN   banco bc              ON bc.id = ct.banco_id
LEFT   JOIN modo_captura mc  ON mc.id = fat.modo_captura_id  
WHERE  cv.controle_upload_arquivo_id = 6906  
AND    fat.parcela = 1  
ORDER  BY fat.data_venda, fat.data_credito
LIMIT  20;

Sintaxis de JOIN y secuencia de combinaciones

En particular, arreglé el engañoso LEFT JOIN a conciliacao_vendas , que se ve obligado a actuar como un simple [INNER] JOIN por el posterior WHERE condición de todos modos. Esto debería simplificar la planificación de consultas y permitir eliminar filas antes en el proceso, lo que debería hacer que todo sea mucho más económico. Respuesta relacionada con explicación detallada:

• Explicar JOIN frente a LEFT JOIN y la sugerencia de rendimiento de la condición WHERE con más detalle

USING es solo una abreviatura sintáctica.

Dado que hay muchas tablas involucradas en la consulta y el orden en que la consulta reescrita une las tablas es óptimo ahora, puede ajustar esto con SET LOCAL join_collapse_limit = 1 para ahorrar gastos generales de planificación y evitar planes de consulta inferiores. Ejecutar en una transacción única :

BEGIN;
SET LOCAL join_collapse_limit = 1;
SELECT ...;  -- read data here
COMMIT;      -- or ROOLBACK;

Más sobre eso:

• Consulta de muestra para mostrar el error de estimación de cardinalidad en PostgreSQL
• El excelente manual sobre Control del planificador con Explicit Cláusulas JOIN

Índice

Agregue algunos índices en tablas de búsqueda con lotes o filas (no es necesario solo para un par de docenas), en particular (tomado de su plan de consulta):

Eso es particularmente extraño, porque esas columnas se ven como columnas de clave principal y ya debería tener un índice...

Entonces:

CREATE INDEX conta_pkey_idx ON public.conta (id);
CREATE INDEX loja_pkey_idx ON public.loja (id);
CREATE INDEX loja_extensao_pkey_idx ON public.loja_extensao (id);

Para hacer esto realmente gordo, un índice de varias columnas sería de gran servicio:

CREATE INDEX foo ON Table1 (parcela, data_venda, data_credito);