- Navios
- 23 de setembro de 2026 às 12:33 UTC
- Autor
- Kamo
- Enviar
- 6add2f1
pg stat statements colocam o changelog público no topo do banco de dados por um distância: o slug lookup e os dois lookups vizinhos correram ~905K vezes cada um a ~245 ms — juntos cerca de 70% de todo o tempo que YugabyteDB gastou executando declarações. O site de marketing transforma cada página de entrada por solicitação (~19K entradas x 22 locais), assim os rastreadores mantê-los ocupados, e cada custo de visualização três leituras quase completas de commit logs: - findBySlug utilizado `commitHash like :prefix E projeto IN (...)`. O índice único no commit hash é HASH-sharded, por isso nenhuma verificação prefixo nunca foi possível (o comentário alegando que o contrário se foi), e com a lista de projetos apresentar o planner caminhado (projeto, date committed) e filtrado Linha pública. Agora é o intervalo semi-aberto [prefixo, prefixo + "~") — todos os tipos de caracteres hex abaixo '~' na colagem C — sobre o novo ix commit logs hash prefix, com o projeto público filtro aplicado em Java para no máximo 16 candidatos. A mesma resposta: exatamente um jogo público ou nada. - mais recente/mais velho comparado `(d > :d OR (d = :d AND id > :id)`, que não dá nenhum índice um lugar para começar. Eles agora dizem `d >= :d AND (d > :d OR id > :id)` (equivalente), então ix commit logs date uid inicia a sua caminhada na entrada. Medido na produção com planos genéricos forçados (o que o servidor do JDBC prepara): slug 2.2 ms (era ~245-316), mais recente 1,3 ms e mais antigo 1,2 ms (era ~190). Os dois índices foram criados por Mão como proprietário e estão gravados em PublicChangelogLookupTest fixa as formas de instrução e o filtro do lado Java (4 de 5 vermelho contra o serviço anterior).
