2008/10/23 Mozart Hasse <[EMAIL PROTECTED]>: >> O valor padr�o para este par�metro � med�ocre mesmo. J� houve
Herr Haße, tua mensagem veio em BASE64 com codificação errada... >> v�rias >> discuss�es sobre aumentar este valor para um valor mais condizente com a >> realidade mas por falta de provas (aka testes) -- que isso n�o >> aumentar� >> o tempo de planejamento para ter o mesmo benef�cio -- ainda n�o >> decidiram se v�o aument�-lo na pr�xima vers�o. > > Que provas eu preciso montar ? Uma base com tabelas de 5000, 30000 e 700000 > registros, alguns índices e uma dúzia de querys 60 vezes mais lentas do que > uma base com esse parâmetro preenchido com valores decentes ? Pode começar por aí, desde que esteja bem documentado... A questão é, a partir de provas tais, achar um equilíbrio entre as necessidades de pequenos sistemas embutidos e grandes sistemas corporativos. > O custo de calcular as estatísticas numa tabela grande até pode parecer > *relativamente* alto, porém calcular essa informação extra nem se compara > com o estrago causado por um TABLE SCAN numa tabela com 1.000.000 de registros > ou mais. A questão é se vale jogar o valor geral para o alto, ou dar um aumento moderado geral e só jogar para bem mais alto determinadas tabelas. E se é necessário 1000 como você propõe, ou no máximo 300 como o Euler propôs. Conversando a gente se entende... -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
