Estranho esse comportamento no postgresql, chegou a rodar alguma query para v... · Crazynds

Estranho esse comportamento no postgresql, chegou a rodar alguma query para ver o tamanho físico de dados ocupados por tabelas e por índices?

Eu falo isso pois algumas vezes criamos diversos índices sem uma análise correta, e ao fazer uma consulta o banco acaba nem usando o índice.

Por exemplo: se eu criar um índice em cima da data de criação e um índices em cima de categoria, e fizer uma consulta onde eu busco um range de data de criação e filtro por uma categoria específica, o postgresql usaria apenas um índice nessa busca.

Dados agregados é pior ainda, existem soluções O(log n) envolvendo segtree em banco de dados que podem reduzir mais ainda o tempo de consulta.

Eu digo isso pois o postgresql é uma ferramenta muito customizavel (já vi gente fazendo cache usando postgresql mais performatico que o redis kkk) só que é necessário muito conhecimento e prática para conseguir ajustar ele pro teu caso. O modo default do postgresql que se usa tudo padrao SQL é no modo "pau pra toda obra", mas para casos mais específicos é necessário estudos mais aprofundados.

opa, obrigado pelo comentário.
sobre a sua pergunta do tamanho da tabela com os índices, fiz uma analise de tamanho usando o PG hero, ele mostra os tamanhos das tabelas de dados e dos índices de forma separada, então esse tamanho é so dos dados.

nao duvido que o PostgreSQL seja muito performático, tanto que usamos timescale DB em outros DBs e ele é muito performático.

o problema em específico nesse cenario que estou testando é por conta do alto volume de dados.
fiz esse teste em um DB pequeno mas o foco é no DB grande (7tb)
comecei os testes nele hoje, o foco principal é reduzir tamanho mesmo, nisso acho o PostgreSQL meio deficitário, acaba ocupando muito espaço com dados vazios (claro, parte da culpa disso é da modelagem dos dados também).

mas ja foi investido muito tempo e dinheiro nesse DB, que no fim das contas não conseguiu entregar nem metade do desempenho e economia que estou percebendo nesse novo DB clickhouse.

mas pra dados com muitas alterações, ainda vamos usar o PostgreSQL, por se encaixar melhor nisso.