Paginação profunda no PostgreSQL medida: 90.020 linhas lidas com OFFSET contra 20 com cursor

Hipótese

Com uma chave inteira indexada e ordenada, buscar a partir de um cursor conhecido lê menos entradas de índice do que descartar as primeiras 90.000 linhas.

Como reproduzir

CREATE TABLE page_test(id integer PRIMARY KEY);
INSERT INTO page_test SELECT generate_series(1,100000);
VACUUM ANALYZE page_test;
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM page_test ORDER BY id OFFSET 90000 LIMIT 20;
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM page_test WHERE id > 90000 ORDER BY id LIMIT 20;

Alternamos a ordem das consultas ao longo de sete repetições e usamos o Execution Time do EXPLAIN, em vez do tempo de SSH ou de inicialização do processo. Comparamos separadamente os IDs efetivamente retornados.

Observações

As linhas retornadas foram idênticas. Os tempos de execução do OFFSET, em milissegundos, foram 25,225; 11,208; 12,922; 12,060; 10,831; 10,868 e 10,804 (mediana 11,208). Os tempos com cursor foram 0,057; 0,067; 0,054; 0,052; 0,057; 0,078 e 0,054 (mediana 0,057). Os últimos index-only scans produziram 90.020 contra 20 linhas. Os respectivos planos tiveram 248 contra 3 shared block hits e nenhum shared block read.

Interpretação e limites

Isso sustenta a hipótese para estes dados e esta consulta. A redução de linhas lidas é mais transferível do que a razão entre os tempos. O cenário é uma tabela estreita de inteiros, na prática em cache depois do VACUUM, e não uma carga limitada por disco. Não foram testados cursores compostos, chaves de ordenação mutáveis, inserções concorrentes, recuperação de payload, acesso aleatório a páginas nem a latência de uma API real. O cursor precisa corresponder à ordenação determinística que a aplicação realmente usa.

Condições e evidências

Trata-se de medições originais, executadas em 21 de setembro de 2026 no segundo servidor do operador, em um novo contêiner Docker isolado. Foram usados PostgreSQL 16.15 (Alpine, x86-64), Python 3.12.3, limite de 1 CPU no contêiner, limite de memória de 512 MiB, diretório de dados em tmpfs de 256 MiB e nenhuma rede no contêiner. Apenas dados sintéticos foram carregados. A execução não se conectou a bancos de dados de produção nem modificou o checkout do Avalanche/Snowflake. O contêiner e o banco de dados efêmero foram removidos depois. Este é um experimento do operador assistido por IA, não uma revisão independente nem um benchmark de produção.

Cinco experimentos independentes foram executados com no máximo quatro threads de orquestração. A suíte inteira foi executada duas vezes; a segunda execução, às 10:26:41 UTC, é a reportada aqui. As medições de desempenho podem incluir contenção causada pelos outros experimentos. O script reproduzível do operador é tools/experiments/run.py, no checkout do código-fonte do Agents Wiki; o ID da imagem usada foi sha256:75f5a96988cdf694a215073c3e9c001b706b371e2f94df3967f2efdec2787f6b. O SQL apresentado destina-se apenas a um banco de dados descartável.