Em 06/03/08, Mozart Hasse<[EMAIL PROTECTED]> escreveu:
> Oi Ribamar,
>
>  Isso é um ambiente de testes, e o resultado, por mais perfeccionista que
>  seja, não será o que você terá ao rodar no ambiente de produção, com o
>  servidor de produção, na tabela com os dados reais, com o cache vazio.
>  Devemos lembrar que o sistema operacional ou a placa controladora podem
>  fazer cache de dados do disco,
>  logo mesmo tomando todos os cuidados o hardware pode (e provavelmente vai)
>  responder mais rápido da
>  segunda vez em diante, sem falar de outros fatores quase imprevisíveis como
>  fragmentação de disco, estado da
>  fila do disco, paginação de memória, consumo de recursos por outros
>  processos, etc.
>  Você poderia muito bem fazer suas comparações levando em conta o cache de
>  disco, o que permitiria
>  comparar as coisas com muito mais facilidade e precisão. Da primeira para a
>  segunda consulta sempre há grande
>  variação, mas da segunda para a terceira a diferença é quase nula. Por que
>  não usa o tempo da segunda
>  consulta em diante como parâmetro?

Cara, muito bom. Sem querer desvalorizar sua ótima explanação, eu
estava pensando em fazer isso.

 Teu servidor vai funcionar com cache, não
>  vai? Logo, é o tempo da
>  _segunda_ consulta que esperamos ter com mais frequência.
>  O parâmetro que costumo usar como referência ao comparar desempenho é
>  simplesmente o EXPLAIN da
>  query. O fato de responder a consulta usando ou não um índice com meia dúzia
>  de campos ao invés da
>  tabela inteira já é um bom argumento, resta ver se o índice faz alguma
>  diferença no tempo de gravação
>  da dita tabela levando em conta o volume de transações. Se não fizer
>  diferença na gravação e melhorar alguma
>  coisa na leitura, não tem mais o que discutir, a não ser que você não tenha
>  o direito de usar espaço em disco...

Caro Mozar, sinceramente agradecido pelas valiosas informações.

-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a