APRENDER. PRATICAR. EVOLUIR.Conservar a mesma visão
Uma sessão inicia REPEATABLE READ READ ONLY e lê a primeira página. A segunda sessão apaga id 1, altera units em id 4 e insere id 7 antes da fronteira. A primeira sessão lê as páginas restantes dentro da mesma transação e continua a observar os ids e valores originais. Depois do COMMIT, uma nova consulta vê as alterações. O guião confirma estas observações, sem exportar snapshots entre sessões. O requisito ensaiado é estabilidade dessa visão local durante a leitura, não uma garantia de consistência de negócio entre sistemas. Define quando a visão começa, quando termina e o que acontece se a exportação for interrompida antes de ser entregue. Uma leitura prolongada pode manter versões antigas ainda visíveis; define limites de duração e libertação dos recursos. O ensaio não mede bloat ou custo de vacuum.
Evitar a ilusão entre pedidos
Outro grupo termina a transação depois da primeira página. A segunda sessão insere a linha anterior à fronteira e a próxima página inicia uma nova transação, também REPEATABLE READ. A resposta volta a ser [2,3]. Usar o mesmo nome de isolamento em pedidos separados não conserva a visão do primeiro pedido. Uma aplicação web que abre e fecha uma transação por página precisa de explicitar esta fronteira. Pode escolher uma experiência viva, gerar um artefacto de exportação ou adotar outro mecanismo de snapshot com ciclo de vida definido. O laboratório não implementa essas alternativas HTTP e não demonstra a sua recuperação após falha.
Medir trabalho num plano controlado
O guião cria 20000 linhas para alpha e outras 20000 para beta, com um índice em (tenant,rank_key,id). Depois de VACUUM ANALYZE, desativa sequential scan apenas na sessão do ensaio para controlar a comparação. EXPLAIN ANALYZE executa duas consultas que devolvem os mesmos dez ids. O filho Index Only Scan produz 15010 linhas na consulta OFFSET 15000 e dez na consulta após a fronteira (15000,15000); cada scan tem um loop. O nó LIMIT devolve dez em ambos. O relatório guarda contagens e identifica a intervenção no planner. Não mede um SLA, não recomenda desligar sequential scan em produção e não transforma esta razão de linhas numa razão de latência.
Relacionar índice e padrão de acesso
No conjunto de plano, o filtro tenant fixa o primeiro componente do índice e a consulta percorre rank_key e id pela mesma ordem. Esse desenho torna a comparação legível, mas não prova que qualquer índice com os mesmos campos sirva todas as consultas. Mudanças de filtro, sentido da ordem, distribuição ou colunas devolvidas pedem outro plano. Uma revisão deve conservar SQL, parâmetros relevantes, estatísticas e versão usada, além do resultado observado. Em produção, compara trabalho e tempo em condições representativas e inclui o custo de manter índices nas escritas. O laboratório mede um acesso de leitura deliberadamente controlado; não ensaia manutenção de índice sob carga concorrente.
Manter o âmbito em cada página
A consulta com tenant=alpha devolve ids 15001 e 15002 desse tenant. Ao retirar o filtro, a mesma fronteira permite obter alpha 15001 e beta 15001. A ordenação adicional por tenant neste grupo torna o resultado determinístico; não existe autenticação. O teste demonstra uma fuga de âmbito na consulta, não uma auditoria de segurança de uma API. Um cursor não substitui o filtro obrigatório nem a autorização atual do utilizador. Na conceção do contrato, inclui filtros, versão da ordem e ligação ao âmbito autorizado. Se houver assinatura, validade ou proteção contra alteração do cursor, esses controlos precisam dos seus próprios testes; não foram implementados neste guião.
Fechar a decisão de exportação
Num projeto fictício, negócio exige um relatório reconciliável enquanto suporte precisa de uma lista sempre atual. Regista os dois requisitos e evita impor o mesmo contrato a ambos. Para a exportação, define população, visão, ordem, retoma, conservação do artefacto e reconciliação de totais. Para a lista viva, explica a possibilidade de mudanças entre páginas e como a interface lida com elas. Entrega exemplos de inserção, remoção e atualização que permitam reproduzir cada decisão. Os catorze grupos locais ajudam a discutir mecanismos e limites. Aceitação com a aplicação real, volume representativo, autorização e revisão humana continuam necessárias antes de declarar cumprido o compromisso operacional.
python3 content/labs/design-pagination/run.py --postgres-prefix /path/to/postgresql-18.6 --output /tmp/dr-pages-new.json
# Choose a new output path. The script creates and stops its own private cluster.No plano controlado, OFFSET consome 15010 linhas do index scan para devolver dez; keyset consome dez e devolve os mesmos ids.
Armadilhas comuns
Nova transação como snapshot anterior, contagens como milissegundos, desativar scans como otimização universal e cursor como autorização.
Tópicos relacionados: Planos de execução · Snapshots e isolamento
O contrato precisa de uma visão, uma ordem, um âmbito e limites operacionais. Um plano ajuda a medir trabalho, mas não substitui a aceitação no destino.
Referência: Using EXPLAIN · System design patterns; PostgreSQL18 scoped examples; primary guidance consulted 2026-09-30