Armazenar dados derivados no PostgreSQL: colunas geradas ou views materializadas

O que é

A documentação descreve a coluna gerada como "para colunas o que uma view é para tabelas": GENERATED ALWAYS AS (expr) com VIRTUAL (calculada na leitura, sem armazenamento; é o padrão desde o PostgreSQL 18) ou STORED (calculada no insert e no update e gravada em disco). A expressão só pode usar funções imutáveis; não pode referenciar outra coluna gerada, uma subconsulta nem outra tabela, e a coluna não pode ser escrita diretamente. Uma view materializada armazena o resultado de uma consulta arbitrária; REFRESH MATERIALIZED VIEW substitui todo o conteúdo, e a view não pode ser atualizada diretamente.

Por que importa

Ambas substituem o recálculo no código da aplicação, e ambas podem se afastar do que se pretende: uma coluna gerada armazenada custa tempo de escrita e espaço a cada atualização, enquanto uma view materializada devolve linhas desatualizadas até o próximo refresh. Escolher a opção errada resulta em escritas lentas ou em leituras incorretas.

Como aplicar

• Normalização por linha (lower(email), um tsvector construído a partir de título e corpo, um timestamp agrupado em intervalos): use uma coluna gerada STORED, indexada como qualquer outra coluna; o valor está sempre atual. Um índice de expressão é a alternativa quando não se precisa de uma coluna, mas a consulta então precisa repetir a expressão exatamente.
• Valores por linha baratos de calcular e raramente usados em filtros (conversões de unidade, um nome de exibição concatenado a partir de partes): use uma coluna gerada virtual, que não tem custo na escrita.
• Agregações sobre muitas linhas (totais diários, rankings, joins desnormalizados para um dashboard): use uma view materializada com um índice único sobre a sua chave, atualizada por um job agendado com REFRESH MATERIALIZED VIEW CONCURRENTLY. Para CONCURRENTLY, a documentação exige um índice único sobre nomes de colunas, sem expressão nem WHERE, e observa que um refresh simples pode bloquear leitores.
• Exiba o horário do último refresh junto dos dados servidos a partir de uma view materializada e configure um alerta para quando o job de refresh não tiver sido executado.
• Quando um resumo precisa estar atual enquanto as tabelas de base mudam constantemente, mantenha uma tabela de resumo na mesma transação da escrita ou por meio de triggers; uma view materializada atualizada a cada minuto significa um recálculo completo a cada minuto.

Armadilhas

WITH NO DATA deixa a view materializada num estado em que não pode ser lida até o primeiro refresh, e CONCURRENTLY não pode ser usado nessa primeira carga; só um refresh por vez pode estar em execução para cada view. Colunas geradas virtuais não podem usar tipos nem funções definidos pelo usuário. Uma coluna gerada não pode fazer parte de uma chave de partição e não pode ter valor padrão (default) nem definição de identity.