WITH w AS NOT MATERIALIZED ( SELECT * FROM very_very_big_table ) SELECT * FROM w AS w1 JOIN w AS w2 ON w1.key = w2.ref WHERE w2.key = 123;
Hoje, uma consolidação caiu no repositório PostgreSQL, que permite controlar o comportamento do processamento de subconsultas CTE, a saber: agora você pode indicar explicitamente se a subconsulta será materializada separadamente ou se será executada como parte de uma consulta grande.
Isso irá para o PostgreSQL 12 e isso é importante. Vamos ver o porquê
Os programadores adoram o CTE porque ele pode melhorar significativamente a legibilidade do código. Bem, de fato, algumas consultas analíticas podem funcionar com dezenas de tabelas e vários agrupamentos e filtros. Escrever tudo isso em uma grande consulta - garantida a obtenção de algo ilegível. Portanto, usando o operador WITH , sequencialmente, em pequenas subconsultas (que recebem um nome legível por humanos), descrevemos a lógica do trabalho e produzimos o resultado. Muito confortável
Mais precisamente, seria muito conveniente se não fosse uma coisa: o PostgreSQL atual executa essas subconsultas separadamente uma da outra, as materializa (grava o resultado em uma tabela temporária). Isso pode levar a uma desaceleração significativa em comparação com um grande monstro ilegível. Especialmente se as subconsultas CTE retornarem milhões de linhas.
No entanto, há situações em que uma execução separada funciona para o bem: existe um truque de otimização quando é melhor executar parte de uma solicitação complexa separadamente, mas o postgres não entende isso sozinho. Depois, retiramos essa parte da subconsulta CTE.
Em geral, as situações são diferentes, e é por isso que o Postgres 12 fez um commit adicionando as palavras-chave MATERIALIZED e NOT MATERIALIZED , que indicam se a consulta ou a linha deve ser materializada, respectivamente.
Além disso, o comportamento padrão mudou. Agora a subconsulta CTE será incorporada por padrão se o resultado for usado uma vez. Caso contrário, ele se materializará como antes.