Os perigos ocultos de manter tabelas em excesso no PostgreSQL

O raster_overviews é uma view de metadados do PostGIS que lista informações sobre visões agregadas de dados raster, como pirâmides de resolução reduzida usadas em mapas e análise espacial. Ela depende diretamente de catálogos do sistema PostgreSQL (pg_class, pg_attribute, pg_namespace, entre outros) para construir seu resultado. Quando há dezenas de milhares de tabelas, esses catálogos explodem em tamanho: cada tabela gera múltiplas entradas nessas tabelas do sistema (por colunas, índices, constraints), e a view acaba varrendo milhões de linhas de metadados em tempo de execução, mesmo que o dado raster propriamente dito seja pequeno.

Isso não é um bug no PostGIS, nem na view em si: é uma consequência direta da arquitetura de catálogo do PostgreSQL, que carrega metadados em memória de forma não limitada por conexão. A performance cai não por causa da lógica da query, mas porque o planejador precisa ler, analisar e unir milhares de registros de sistema antes de montar o plano, e isso se repete a cada execução, sem cache eficiente para esse tipo de consulta em escala extrema.

A cobertura anterior do CEVIU já havia alertado que cenários de borda, como esquemas com milhares de objetos, tendem a emergir como gargalos silenciosos artigo original. Agora, a nova análise confirma que o problema não é teórico: foi observado em produção, com impacto real em memória (até 500 MB por conexão no CacheMemoryContext) e downtime de upgrade. Antes era um caso hipotético de 'excesso de objetos'; agora é um diagnóstico com evidências técnicas, experimentos reprodutíveis e solução prática, eliminar tabelas, não só otimizar queries.

Para engenheiros de dados que projetam multi-tenancy com schema-per-tenant ou pipelines que geram tabelas dinâmicas (ex: ingestão por partição temporal ou por fonte), esse é um limite físico do PostgreSQL, não um ajuste de configuração. Diferente do bloat ou do vacuuming, que podem ser mitigados com rotinas, o crescimento do catálogo é linear com o número de objetos e afeta operações fundamentais: planejamento de consultas, upgrades com pg_upgrade, inicialização de conexões e até o próprio autovacuum. Ignorar isso leva a degradações progressivas, difíceis de correlacionar com a causa raiz.