Entendo. No caso, eu evitaria usar o "Count" diretamente e, ao invés disso, criaria uma tabela separada para gerenciar a contagem de registros de forma incremental, o que tornaria a operação de paginação muito mais eficiente. Na realidade eu partiria de algumas premissas de manutenção do banco de dados como: 1. Índices por data (366 por ano) com Time-To-Live (TTL) de 1 ano: - Os dados com mais de um ano poderiam ser transferidos para Amazon RDS para fins de compliance, sem a necessidade de manter esses índices ativos no banco principal, o que ajuda a evitar o aumento descontrolado do tamanho do banco. - Como os índices não são interdependentes, acredito que seria mais fácil atualizar um índice por vez, em vez de manter e gerenciar 366 bancos separados. Isso facilita a manutenção e permite um gerenciamento mais eficiente. 2. Sub tabela de contagem para cada índice, para facilitar a paginação sem usar o caro COUNT: - Caso não haja registros no índice de um determinado dia, começaria a contagem com o valor 0. - Se já houver registros, utilizaria um COUNT inicial para pegar o valor atual da contagem, e em seguida, a contagem seria mantida e atualizada via transações incrementais para cada novo registro. Assim, sempre que for necessário realizar paginação, a contagem já estará disponível de forma simples e rápida, com um SELECT. Mas, obviamente, isso é especulação minha com base nas informações fornecidas. Foi mais um exercício lógico sobre como eu estruturaria a arquitetura no PostgreSQL, do que uma solução definitiva para a sua situação.