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.