Hur man optimerar frågan postgres

Prova denna omskrivna version:

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;

JOIN-syntax och sekvens av kopplingar

Jag fixade särskilt den vilseledande LEFT JOIN till conciliacao_vendas , som tvingas fungera som en vanlig [INNER] JOIN av den senare WHERE skick i alla fall. Detta bör förenkla frågeplanering och göra det möjligt att eliminera rader tidigare i processen, vilket borde göra allt mycket billigare. Relaterat svar med detaljerad förklaring:

Förklara JOIN vs. LEFT JOIN och WHERE-förslag till prestanda i mer detalj

USING är bara en syntaktisk stenografi.

Eftersom det finns många tabeller inblandade i frågan och den ordning som den omskrivna frågan ansluter till tabeller är optimal nu, kan du finjustera detta med SET LOCAL join_collapse_limit = 1 för att spara planering och undvika sämre frågeplaner. Kör i en enskild transaktion :

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

Mer om det:

Index

Lägg till några index på uppslagstabeller med partier eller rader (inte nödvändigt för bara ett par dussintals), särskilt (tagna från din frågeplan):

Det är särskilt märkligt eftersom dessa kolumner ser ut som primära nyckelkolumner och borde redan ha ett index ...

Så:

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);

För att göra detta riktigt fett, ett flerkolumnindex skulle vara till stor tjänst:

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