Re: [pgbr-geral] Compilação do Postgr eSQL 8.1 para processamento simétrico
Valeu pessoal, Deixa dar um resumo do meu cenário para ficar mais claro o problema. Conversando com o gerente do projeto acho que achei o problema ... é tudo ;-) e o sistema teria que ser todo reescrito: Deixa eu contar parte da minha história: Nós temos uma base de dados de espécies botânicas, e como vocês deve lembrar do seu tempo de ginásio, que uma planta possui um reino, um filo, uma família, um gênero, uma espécie, um tipo, . Isso chama-se 'taxon'. E apesar de não ser TÃO complicado é chato de trabalhar pois são informações que precisam ser processadas com algoritimos de árvore. Pra simplificar o cenário, basicamente eu tenho duas tabelas (é muito mais do que isso, mas como eu disse é só pra simplificar). Dadas essas duas tabelas: Uma tem essa hierarquia, e a outra são dados da espécie em si. O problema começa quando eu preciso listar minhas espécies. Não basta apenas dar um SELECT na tabela espécies, é preciso fazer uma varredura na tabela de taxons para listar toda a 'hierarquia genealógica' a qual a aquela espécie pertence. O resultado... o processamento é lngo!!! E não para por ai. Se um taxon desse é modificado, por algum motivo a situação é mais complicada, pois eu preciso inserir/editar vários itens na tabela de taxons. Isso é uma loucura e gera um caos, produzido por inúmeras triggers e store-procedures. E assim começa a penitencia, mas tem mais, eu recebo diariamente um lote de dados em um tabelão que precisa ser desmembrado, filtrado e ordenado para que possa se enquadrar neste perfíl e depois ser efetivamente importado. Tudo isso tem 'chupado' recursos do meu sistema. Em 19/06/07, Fabio Telles [EMAIL PROTECTED] escreveu: Em 18/06/07, Welington R. Braga[EMAIL PROTECTED] escreveu: Valeu Euler, Já monitorei, mas nada indica qual processador esta em uso e o problema continua: Eu tenho uma consulta que roda periodicamente importando dados de uma tabela para outra fazendo apenas algumas conversões de dados e numa quantidade na ordem de milhares de registros. Após executar essa consulta o acesso a base principal fica muito lento. O problema pelo que percebi é que quando a consulta roda, o banco joga todos os registros para memória e lá ficam até ocorrer um commit. Sim, isso é normal. Sempre que vamos rodar rotinas em lote, temos que tomar alguns cuidados para não arriar o banco: - Desativar índices e chaves - Tentar usar COPY ao invés de INSERT - Tentar usar TRUNCATE ao invés de DELETE - Tentar usar tableas temporárias ao invés de um commit no final do processo. - Tentar paralelizar as operações longas utilizando mais de um processo separado - Tentar particionar tabelas grandes - Distribuir melhor os dados em grupos físicos e lógicos de discos distintos. Particularmente, parece que o seu commit vai consumir muito recurso no final. Cada caso é um caso, mas movimentar milhões de linhas e dar um commit só no final acaba com os recursos de qualquer SGDB, até do DB2. Este tipo de situação deve ser evitado a todo custo. Existem várias técnicas para evitar isso. Dá bem mais trabalho, mas o desempenho é fantástico. Bom, de qualquer forma, parece que seu PostgreSQL está ótimo, mas seu processo precisa ser otimizado. []s Fábio Telles -- site: http://www.midstorm.org/~telles/ e-mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] sip:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Welington Rodrigues Braga -- Web: http://gtk-br.welrbraga.t5.com.br MSN: welrbraga[*]msn·com Gtalk: welrbraga[*]gmail·com Yahoo / Skype: welrbraga ICQ: 52789331 Em tudo somos atribulados, porém não angustiados; perplexos, porém não desanimados; perseguidos, porém não desamparados; abatidos, porém não destruídos; - 2Co 4:8,9 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] otimizacao de queries
Euler Luiz Rafael Culik Guimaraes wrote: Em segundo lugar, é problema de performance? EXPLAIN. Não mande a consulta ou estrutura de tabelas a não ser que alguém peça. Para análise de performance, é essencial a versão, pois várias otimizações são feitas durante as versões. postgres 64bits versao 8.1.6 em redhat enterprise 4 E o EXPLAIN? abaixo a query e seu explain select b.inrcmv, b.inrndc, b.inrpur, a.cnrfor, c.movfor, b.inrcme, a.cnrure, a.cnrutr, a.cnrdrm, a.cnrnnf, a.cnrenf, d.concpg, a.cnrvnf, b.inrvlr, a.cnricm, b.inripi, a.cnrpis, a.cnrcofin, b.inrqtg, '' as romplc, a.cnrbfu, a.cnrvim, a.cnrcf2, c.movpli, q.flagsit, a.cnrsnf, a.cnrtim, c.movdoc from qr_dbf_sie3000_log as q join granol_sie3000_dbf as a on q.cnrnum = a.cnrnum join granol_sie3200_dbf as b on a.cnrnum = b.inrnum join sif00_con1000_dbf as d on b.inrndc = d.connum||trim(to_char(d.conuni,'00')) join sif50_mov1000_dbf as c on b.inrnum = c.movnnr where a.cnrsis = 1 and b.inrdco = 1 and b.inrcmv in ( 1,4,5,20,29,44,45,49,67,68,70,71,73 ) order by q.cnrnum LIMIT 1 resultado do plan Limit (cost=37.47..37.47 rows=1 width=326) (actual time=0.213..0.213 rows=0 loops=1) - Sort (cost=37.47..37.47 rows=1 width=326) (actual time=0.202..0.202 rows=0 loops=1) Sort Key: q.cnrnum - Nested Loop (cost=5.88..37.46 rows=1 width=326) (actual time=0.030..0.030 rows=0 loops=1) - Nested Loop (cost=5.88..32.62 rows=1 width=316) (actual time=0.024..0.024 rows=0 loops=1) - Nested Loop (cost=4.86..21.90 rows=1 width=297) (actual time=0.020..0.020 rows=0 loops=1) Join Filter: (inner.cnrnum = outer.inrnum) - Hash Join (cost=4.86..17.07 rows=1 width=117) (actual time=0.015..0.015 rows=0 loops=1) Hash Cond: (((outer.connum)::text || btrim(to_char(outer.conuni, '00'::text))) = (inner.inrndc)::text) - Seq Scan on sif00_con1000_dbf d (cost=0.00..10.80 rows=80 width=29) (actual time=0.003..0.003 rows=0 loops=1) - Hash (cost=4.86..4.86 rows=1 width=108) (never executed) - Index Scan using granol_sie3200_dbf_12346 on granol_sie3200_dbf b (cost=0.00..4.86 rows=1 width=108) (never executed) Index Cond: (inrdco = 1::numeric) Filter: ((inrcmv = 1::numeric) OR (inrcmv = 4::numeric) OR (inrcmv = 5::numeric) OR (inrcmv = 20::numeric) OR (inrcmv = 29::numeric) OR (inrcmv = 44::numeric) OR (inrcmv = 45::numeric) OR (inrcmv = 49::numeric) OR (inrcmv = 67::numeric) OR (inrcmv = 68::numeric) OR (inrcmv = 70::numeric) OR (inrcmv = 71::numeric) OR (inrcmv = 73::numeric)) - Index Scan using granol_sie3000_dbf_12346 on granol_sie3000_dbf a (cost=0.00..4.82 rows=1 width=180) (never executed) Index Cond: (cnrsis = 1::numeric) - Bitmap Heap Scan on qr_dbf_sie3000_log q (cost=1.02..10.63 rows=7 width=19) (never executed) Recheck Cond: (q.cnrnum = outer.cnrnum) - Bitmap Index Scan on qr_dbf_sie3000_log_pkey (cost=0.00..1.02 rows=7 width=0) (never executed) Index Cond: (q.cnrnum = outer.cnrnum) - Index Scan using sif50_mov100c_06 on sif50_mov1000_dbf c (cost=0.00..4.82 rows=1 width=52) (never executed) Index Cond: (outer.inrnum = c.movnnr) Total runtime: 1.210 ms query select b.inrcmv, b.inrndc, b.inrpur, a.cnrfor, d.movfor, b.inrcme, a.cnrure, a.cnrutr, a.cnrdrm, a.cnrnnf, a.cnrenf, '' as concpg, a.cnrvnf, b.inrvlr, a.cnricm, b.inripi, a.cnrpis, a.cnrcofin, b.inrqtg, c.romplc, a.cnrbfu, a.cnrvim, a.cnrcf2, d.movpli, q.flagsit, a.cnrsnf, a.cnrtim, d.movdoc from qr_dbf_sie3000_log as q join granol_sie3000_dbf as a on q.cnrnum = a.cnrnum join granol_sie3200_dbf as b on a.cnrnum = b.inrnum join granol_sie3300_dbf as c on q.cnrnum = c.romnum join sif50_mov1000_dbf as d on a.cnrcon = d.movcon and a.cnruni = d.movunc and a.cnrnfr = d.movnpr where ( b.inrdco = 1 or a.cnrlrt = 70 ) and b.inrcmv in (21,49,72) and c.romtip = 'D' order by q.cnrnum LIMIT 1 resultado do plano Limit (cost=36.50..36.51 rows=1 width=331) (actual time=0.053..0.053 rows=0 loops=1) - Sort (cost=36.50..36.51 rows=1 width=331) (actual time=0.046..0.046 rows=0 loops=1) Sort Key: q.cnrnum - Nested Loop (cost=6.20..36.49 rows=1 width=331) (actual time=0.025..0.025 rows=0 loops=1) Join Filter: ((outer.cnrcon = inner.movcon) AND (outer.cnruni = inner.movunc)) - Nested Loop (cost=6.20..31.65 rows=1 width=328) (actual time=0.020..0.020 rows=0 loops=1) - Nested
Re: [pgbr-geral] Stored procedures
On 6/18/07, Luiz Claudio Aleixo [EMAIL PROTECTED] wrote: Bom dia a todos, estou inciando no postgres com Stored procedures e triggers, alguém me indica algum material e alguma ajuda na criação para criação dessa função? http://www.postgresql.org/docs/8.1/static/plpgsql.html -Leo -- Leonardo Cezar http://www.hostsystems.com.br http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Informações sobre Postgresql
o manual[1] é vosso amigo. [1] http://pgdocptbr.sourceforge.net/pg80/index.html On 6/17/07, Darlon [EMAIL PROTECTED] wrote: Olá. Estou desenvolvendo um trabalho sobre postgresql e estou enfrentando dificuldades em obter informações sobre sua implementação. Procuro informações sobre Recuperação de Falhas, como falha de transação e de sistema, Gerenciamento de transações e Integridade de dados. Se alguém puder me ajudar ao menos informando alguns links sobre isso... Desde já agradeço. Darlon. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Sebastian Selau Webber Colombo Calma, um dia desses eles vão deixar de usar java e banco do brasil vai voltar a funcionar normalmente... hehehehe ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Compilação do PostgreSQL 8.1 para processamento simétrico
Welington R. Braga wrote: Deixa dar um resumo do meu cenário para ficar mais claro o problema. Conversando com o gerente do projeto acho que achei o problema ... é tudo ;-) e o sistema teria que ser todo reescrito: corte Dadas essas duas tabelas: Uma tem essa hierarquia, e a outra são dados da espécie em si. Enquanto o PostgreSQL não aceita consultas hierárquicas, não aconselho que use tabelas autorelacionadas que vão ter muitas consultas hierárquicas. :( O ideal como você mesmo adimitiu é reestruturar o sistema para separar a informação. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco de dados Orientado a objeto
On 6/19/07, Roberto Baselio Lopes [EMAIL PROTECTED] wrote: Bom dia, estou procurando algum material sobre banco de dados orientado a objeto para dar inicio ao meu TCC, gostaria de saber se você possui algum material sobre o assunto Infelizmente não. Mas você encontra na web, dê uma procurada no google. []'s -- wallace reis/wreis Núcleo de Biologia Computacional e Gestão de Informações Biotecnológicas/LABBI ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
