me preocupa esse mysql rodando junto, até por que acredito que o apache exija mais processamento... estou "dormindo" na frente do pc agora... amanhã dou uma pesquisada sobre esse meu palpite e vejo se descubro uma forma de te ajudar!?
abraço On 4/4/07, Everton Luís Berz <[EMAIL PROTECTED]> wrote:
Sebastian, estou passando os dados que pediu. Gostaria que entendessem que apesar das mudanças nas configurações serem bem vindas eu também ficaria grato em saber se o modo que eu estou fazendo as consultas é viável, e se mais alguém faz (ou será q só eu tenho este tipo de tela?), ou como faz. Obrigado. Hardware: Processador (quantidade: 1) - Intel(R) Xeon(TM) CPU 2.80GHz (2791.072 MHz) Memória RAM - 883MB Hard Disk (quantidade: 1) - SCSI 30gb Software: Linux Slackware 9.1 - Kernel 2.4.22 PostgreSQL 8.2.0 Mysql 4.0.15a Apache 2.0.52 + PHP 4.3.10 Apache 2.0.54 + PHP 5.1.4 postgresql.conf (configurações que estão diferentes do padrão): shared_buffers = 256MB (já tentei aumentar e não notei diferença) temp_buffers = 32MB worm_mem = 32MB max_fsm_pages = 153600 wal_buffers = 256kb commit_delay = 5000 checkpoint_segments = 20 checkpoint_timeout = 30min stats_start_collector = on (necessário por causa do autovacuum) autovacuum = on autovacuum_naptime = 30min Observação: a minha base é 90% do tempo utilizada para consultas. Então não preciso me preocupar com otimização para escrita. -- Everton Sebastian Selau Webber Colombo escreveu: > enfim, acho que discutir a modelagem do ER do colega PODE (ao meu ver, > pode não ser isso) não resolver o problema, certo? > > everton, seria interessante tu mandar as tuas configurações do > postgresql.conf pra darmos uma olhada, quem sabe, alguma mudança lah > possa resolver o teu problema. se tu puder, descreva também a tua > máquina, sistema operacional e aplicativos que concorrem com o pg, certo? > > abraço! > > On 4/3/07, *Everton Luís Berz* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Wallace Reis escreveu: > > On 4/3/07, Leandro Guimarães Faria Corcete DUTRA > > <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > >> Sem analisar o código-fonte (que é meio demais para eu > fazer na lista), > >> só constato que tuas tabelas são ligeiramente gordinhas por > terem chaves > >> artificiais quando têm chaves naturais perfeitamente boas. > > > > Acredito que vc se confundiu. Chaves naturais saum coisas como CPF, > > RG, etc. Posso estar enganado, mas nao vejo chave natural em > "turma" e > > "turno". E mais, nao acho bom usar chaves naturais como PK's. > > > > Bom, mesmo se existisse chave natural em alguma das tabelas quero > deixar > claro q não vou deixar de usar chaves artificiais. Então o ER segue > assim para o problema de performance que estou tendo. > Este foi um padrão adotado aqui pela equipe e já usamos a muito > tempo. Com uma rápida pesquisada vemos que o uso de chaves artificiais > tem mais vantagens do que chaves naturais: > http://www.agiledata.org/essays/keys.html > http://thinkoracle.blogspot.com/2005/06/natural-vs-synthetic-keys.html > > -- > Everton > _______________________________________________ > Grupo de Usuários do PostgreSQL no Brasil > Antes de perguntar consulte o manual > http://pgdocptbr.sourceforge.net/ > > Para editar suas opções ou sair da lista acesse a página da lista em: > http://pgfoundry.org/mailman/listinfo/brasil-usuarios > > > > > -- > Atenciosamente, > Sebastian Selau Webber Colombo _______________________________________________ Grupo de Usuários do PostgreSQL no Brasil Antes de perguntar consulte o manual http://pgdocptbr.sourceforge.net/ Para editar suas opções ou sair da lista acesse a página da lista em: http://pgfoundry.org/mailman/listinfo/brasil-usuarios
-- Atenciosamente, Sebastian Selau Webber Colombo
_______________________________________________ Grupo de Usuários do PostgreSQL no Brasil Antes de perguntar consulte o manual http://pgdocptbr.sourceforge.net/ Para editar suas opções ou sair da lista acesse a página da lista em: http://pgfoundry.org/mailman/listinfo/brasil-usuarios
