Bom, quero contar minha história ...quem sabe posso ajudar ou atrapalhar !!!!
Tive uma tabela na base de dados que faz a seguinte conta.... Numero de clientes.. : 1089 Numero médio de equipamentos por cliente : 4 Numero de eventos que gera cada equipamento por hora: 8 (eventos gerados via IP) Numero de dias acumulado no banco : 1 ano Tabela Eventos = 1089 *4 * (8*24*365) = 305.268. 480 Que loucura !!!!! Comecei a ter muitos problemas em relação a consultas destes eventos, porque todos os clientes internos e externos a acessavam e ainda bem que não tinha update ou delete desta tabela ! Uffffaaaa ! Claro tentei várias soluções e nada ! Continuava lento que dói. Tive a idéia infeliz de . 1. Criar um esquema de eventos 2. Mover a tabela eventos para este schema (cli, eqp, dta, eve, dta, hms). 3. Criar tabelas (cli_XXXXXX) de herança da tabela de eventos no schema eventos 4. Criar tabelas (eqp_XXXXXX) de herança das tabelas cli_XXXXXX no schema 5. Criar dinamicamente as tabelas de herança no cadastro de clientes e equipamentos através de trigger; 6. Alterar todas as funções e trigger para realizar tratamento dinamicamente. 7. Alterar a regra de negócio para o banco de dados em relaçãoa eventos. 8. Outras coisitas mais Resultado ! Consegui atender a necessidade do cliente em questão a performance e não tive mais problemas. Hoje em outro cliente estou desenvolvendo esta mesma regra para um sistema de Gestão de Estoque e Financeiro (Saldos, extratos...). PS. Esqueci de dizer que ainda tem 678 clientes que enviam dados via telefone (média de 24 eventos dia). Entendam não sou DBA, mas sim um simples programador. Grande Dutra, > > 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... Bom, basta à cúpula do Postgres definir um padrão para esse tipo de informação então. Enquanto ficar no julgamento subjetivo valor nenhum vai mudar. > A questão é, a partir de provas tais, achar um equilíbrio entre as > necessidades de pequenos sistemas embutidos e grandes sistemas > corporativos. Bom, se temos diversos tipos de uso para o Postgres, cada qual com suas peculiaridades, por que não criar logo um arquivo de configuração para cada perfil? Imaginando um mundo melhor: o sujeito responderia 3 ou 4 perguntas sobre seu hardware, 1 ou 2 sobre o uso mais frequente do servidor e o instalador já coloca no lugar um arquivo .config bem próximo do que ele precisa. Duas ou 3 perguntas na hora de criar o banco de dados (resultando num monte de SETs que usam essas perguntas e a configuração do servidor para chegar num conjunto de opções decente) também facilitariam muito as coisas para o DBA. Claro, isso ainda fica meio longe do mundo perfeito do servidor auto-configurável, mas tentar ir nessa direção (ao menos para ir para o mesmo lado dos que estão quase lá) não seria nada mal... > > 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. 1000 numa tabela pequena gera um pouco de desperdício, mas não é muito, já que a tabela é pequena e o processamento sobre ela não é grande coisa. Agora, 300 numa tabela grande tem boa chance de ser um desastre. Bom, estamos de novo em julgamentos subjetivos, tentemos colocar alguma objetividade: Já que as discussões anteriores sobre aumentar esse valor acabaram por falta de provas de que um novo valor seria mais interessante, mesmo que contrário aos que já testaram com valores maiores e encontraram melhores resultados, que tal propor a essas mentes tão convictas que montem um ambiente em que esses valores proporcionem um desempenho tão maravilhoso quando comparado ao resultado de nossos experimentos? O ônus da prova cabe a quem afirma. Quem afirmou que 10 é um bom valor a ponto de não mudá-lo nem atendendo a pedidos, que prove. Mozart Hasse _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
