Re: [pgbr-geral] Duvidas quanto ao desempenho
Você poderia postar pra nós o seu arquivo .conf, assim saberemos o que foi modifcado, e também os índices dessas tabelas. 2009/9/30 Jose adriano Alves alves.jadri...@gmail.com Voce ja rodou algum analise no banco?? 2009/9/29 crgpww crg...@bol.com.br Olá pessoal, sou novo na lista e estamos começando a trabalhar a pouco tempo com o pg.. Estamos com um volume grande de dados e naturalmente estamos levando bastante tempo para operar com as tabelas, no entanto estamos achando que o desempenho está muito abaixo do esperado ou normal.. Situações que ilustram bem o que está acontecendo são as as seguintes atualizações... UPDATE public.set08 SET hcons1 = c.campo46, hcons2 = c.campo47, . . . hcons24 = c.set_2008_kwh FROM consumo c WHERE NUM_INST = c.num_instala; Esta operação tem levado em média 20 horas sem mais nenhuma operação acontecendo em paralelo no banco... se houver o desempenho piora pra pelo menos mais 4 horas.. Nesta tabela que está sofrendo update ao todo sao 115 colunas com 5,5 milhões de registros, que representam cerca de 2,5 gb de dados num arquivo texto... A tabela consumo é constiuida de 75 colunas de numeros inteiros, tem 4 milhões de registros aproximadamente, existindo um indice para num_instala. Nas tabelas que sofrem a operação, nesse caso set08 não há indice sobre NUM_INST, com o índice o desempenho piorou em 4 horas praticamente... O segundo update é muito mais simples mas demora demais também, cerca de 6 horas. UPDATE set08 SET hcons19 = 0 where hcons19 is null; Lendo algumas outras listas e conversando com amigos mais experientes em PG eles me sugeriram pequenas alterações no arquivo .conf, no sentido de aumentar memória e cache mas tais mudanças nao ajudaram em nada o desempenho.. O S. O. é Windows XP Professional com Sp3, e o PostgreSQL é versão 8.3... A Márquina é um Intel Core 2 Quad 2.83Ghz com 3 GB de RAM... Vocês poderiam me dizer se estes tempos de execução estão normais? A expectativa era que o desempenho seria bem melhor.. o que poderia ser feito para melhorar? Abraço e Obrigado, Gustavo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att. José Adriano Alves Analista de Sistemas - Móveis Gazin. Cel..: +55 44 8802 3994 Fone: + 55 44 3663 8000 - 2319 Mail: alves.jadri...@gazin.com.br MSN: jose.adri...@gazin.com.br Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signatário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN. Antes de imprimir pense em seu compromisso com o Meio Ambiente ___ 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
Re: [pgbr-geral] Duvidas quanto ao desempenho
Meu amigo... Só uma dúvida... Que tipo de tabela é essa que vc está dando update? Não sistema real e sim testes, certo??? Outra coisa... Você já rodou um EXPLAIN para saber como está sendo feito esse update? A pulga que está atrás da orelha é: Como assim atualizar milhões de registros?? 2009/9/30 Rafael Domiciano rafael.domici...@gmail.com Você poderia postar pra nós o seu arquivo .conf, assim saberemos o que foi modifcado, e também os índices dessas tabelas. 2009/9/30 Jose adriano Alves alves.jadri...@gmail.com Voce ja rodou algum analise no banco?? 2009/9/29 crgpww crg...@bol.com.br Olá pessoal, sou novo na lista e estamos começando a trabalhar a pouco tempo com o pg.. Estamos com um volume grande de dados e naturalmente estamos levando bastante tempo para operar com as tabelas, no entanto estamos achando que o desempenho está muito abaixo do esperado ou normal.. Situações que ilustram bem o que está acontecendo são as as seguintes atualizações... UPDATE public.set08 SET hcons1 = c.campo46, hcons2 = c.campo47, . . . hcons24 = c.set_2008_kwh FROM consumo c WHERE NUM_INST = c.num_instala; Esta operação tem levado em média 20 horas sem mais nenhuma operação acontecendo em paralelo no banco... se houver o desempenho piora pra pelo menos mais 4 horas.. Nesta tabela que está sofrendo update ao todo sao 115 colunas com 5,5 milhões de registros, que representam cerca de 2,5 gb de dados num arquivo texto... A tabela consumo é constiuida de 75 colunas de numeros inteiros, tem 4 milhões de registros aproximadamente, existindo um indice para num_instala. Nas tabelas que sofrem a operação, nesse caso set08 não há indice sobre NUM_INST, com o índice o desempenho piorou em 4 horas praticamente... O segundo update é muito mais simples mas demora demais também, cerca de 6 horas. UPDATE set08 SET hcons19 = 0 where hcons19 is null; Lendo algumas outras listas e conversando com amigos mais experientes em PG eles me sugeriram pequenas alterações no arquivo .conf, no sentido de aumentar memória e cache mas tais mudanças nao ajudaram em nada o desempenho.. O S. O. é Windows XP Professional com Sp3, e o PostgreSQL é versão 8.3... A Márquina é um Intel Core 2 Quad 2.83Ghz com 3 GB de RAM... Vocês poderiam me dizer se estes tempos de execução estão normais? A expectativa era que o desempenho seria bem melhor.. o que poderia ser feito para melhorar? Abraço e Obrigado, Gustavo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att. José Adriano Alves Analista de Sistemas - Móveis Gazin. Cel..: +55 44 8802 3994 Fone: + 55 44 3663 8000 - 2319 Mail: alves.jadri...@gazin.com.br MSN: jose.adri...@gazin.com.br Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signatário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN. Antes de imprimir pense em seu compromisso com o Meio Ambiente ___ 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 -- Att. José Adriano Alves Analista de Sistemas - Móveis Gazin. Cel..: +55 44 8802 3994 Fone: + 55 44 3663 8000 - 2319 Mail: alves.jadri...@gazin.com.br MSN: jose.adri...@gazin.com.br Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signatário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN. Antes de imprimir pense em seu compromisso com o Meio Ambiente ___
[pgbr-geral] Res: Res: Res: Res: Performa nce usando funções em PLPGSQL comparadas ao PL/SQL no Oracle
Caro William; Obrigado pela resposta. Tenho vários programas em PL/SQL compostos por milhares de linhas, que efetuam uma série de cálculos, utizando, inclusive, de recursividade, e gostaria de portá-los para o Post. Infelizmente, na versão 8.2.7, tais ficaram extremamente lentos, inviabilizando uma das etapas do projeto. Não cheguei a testar em nenhuma outra versão. A fim de tentar descobrir o porquê deste problema, recorrí à esta lista, colocando duas funções apenas para exemplificar o mesmo e entendí, segundo explicações dos colegas, que o PL/pgSQL não é a linguagem mais apropriada para este tipo de operação. Agradeço à você e aos demais integrantes da lista por me auxiliarem. Márcio de Figueiredo Moura e Castro De: William Leite Araújo william.ara...@grupoquali.com.br Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Terça-feira, 29 de Setembro de 2009 15:03:07 Assunto: Re: [pgbr-geral] Res: Res: Res: Performance usando funções em PLPGSQL comparadas ao PL/SQL no Oracle 2009/9/21 MARCIO CASTRO marciomouracas...@yahoo.com.br Caro Rafael: Obrigado pela resposta. A select fib(35); retorna 9227465, e select fnc_fibonacci(35) retorna 14930352. Não sei qual está certa ou errada. Estou utilizando a 8.2.7 por a mesma já estar instalada aquí e no cliente. A versão 8.4 tem WITH RECURSIVE, mas tal não seria compatível com o mesmo código escrito no Oracle. A minha intenção ao usar o fibonacci foi para mensurar performance. Eu não sabia que o Postgres não trata a recursividade corretamente, portanto, vou desconsiderá-la. De qualquer forma, também utilizei um outro exemplo com um simples LOOP (function1), e a diferença também foi absurda. Não conheço o Oracle, mas sei que o Portgresql usa parâmetros de configuração bem modestos e que a versão 8.4 possui inúmeros incrementos de performance em relação à 8.2. Além disso, TODO procedimento PLPGSQL roda com isolamento de transação. Assim sendo, a resposta do seu procedimento sempre será 0. Para pegar o instantâneo do tempo dentro da função, use timeofday(). Baseado nestes, entendí que o PL/pgSQL é muito inferior em termos de performance do que o PL/SQL no Oracle. Na minha opinião, um entendimento precipitado. A alguns anos atrás, na versão 8.1 do Postgresql, criei procedimentos que trabalhavam na migração de dados cujo tipo principal das chaves era NUMERIC. Bastou trocar o tipo para INTEGER e tive ganhos obcenos de tempo (6 horas para 6 minutos, + ou - ) Por favor, me desculpe se escreví alguma bobagem, ou não fui claro o suficiente. Ficarei muito agradecido se você ou os demais membros postarem mais dicas de performance ou outros exemplos que eu possa utilizar. Entenda também que a diferença de performance foi tão grande à ponto de eu desconfiar de um problema no servidor Linux. Atenciosamente, Márcio de Figueiredo Moura e Castro -- William Leite Araújo Mobile Solution Manager - QualiConsult Analista de Banco de Dados Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.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] restaurar banco de dados
On Thursday 17 September 2009 11:57:09 Nelson Marisco wrote: Prezado Roberto Mello Obrigado pelo retorno... Bem, estava temendo isso...fazer as modificações ocorridas esse tempo todo... Bem, como não sou da área de programação...pelo que vc. escreveu...dá para editar o SQL gerado e fazer as adequações e depois aplicar o PG_RESTORE!!! Sendo assim, qual editor vc. recomendaria para usar Isso eatá muito antigo, e a thread ficou separada, mas pelo que entendi você usa o Windows. Não é a minha praia, mas quando preciso disso tenho usado o pspad: http://www.pspad.com/, só uma dica prefiro deixa-lo em inglês, uso muito as teclas de atalho (rato == atraso de vida :) ), e em português fica alguns conflitos, não sei se foi corrigido. Quanto ao pg_restore e o .sql o Fabrízio já alertou... para que haja o reconhecimento a posteriore ... Saudações NM -- Universidade Federal de Mato Grosso do Sul - UFMS []'s -- Johnny Taylor Faria Chaves - LUN 157066 www.brdados.com.br - jfcha...@brdados.com.br Eu não posso mais, se você pode, doe sangue! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Res: Res: Res: Res: Performan ce usando funções em PLPGSQL comparadas ao PL/S QL no Oracle
Márcio bom dia 2009/9/30 MARCIO CASTRO marciomouracas...@yahoo.com.br Caro William; Obrigado pela resposta. Tenho vários programas em PL/SQL compostos por milhares de linhas, que efetuam uma série de cálculos, utizando, inclusive, de recursividade, e gostaria de portá-los para o Post. Infelizmente, na versão 8.2.7, tais ficaram extremamente lentos, inviabilizando uma das etapas do projeto. Não cheguei a testar em nenhuma outra versão. A fim de tentar descobrir o porquê deste problema, recorrí à esta lista, colocando duas funções apenas para exemplificar o mesmo e entendí, segundo explicações dos colegas, que o PL/pgSQL não é a linguagem mais apropriada para este tipo de operação. Agradeço à você e aos demais integrantes da lista por me auxiliarem. Apenas para complementar suas conclusões A versão 8.4 possui uma funcionalidade que trata recursividade. Sugiro dar uma olhada caso realmente você precise de recursividade. Alias fiz uns testes num banco com uma tabela com ~ 140.000.000 de linhas e ficou muito bom. http://www.pgcon.org/2009/schedule/track/Version%208.4/181.en.html Atte, -- Marcelo Costa www.marcelocosta.net - “You can't always get what want”, Doctor House in apology to Mike Jagger ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SQL SELECT dinâmico em Pl/PgSQL
2009/9/30 Tiago Adami adam...@gmail.com: iValor ALIAS FOR $3; BEGIN -- E aqui, o que fazer??? -- SELECT cNomeColuna FROM cNomeTabela WHERE cNomeColuna = iValor; corte Pergunta: Há como executar um SQL SELECT de forma dinâmica dentro da função que possa retornar um valor? Sim, veja o EXECUTE na documentação do PL/pgSQL. Roberto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SQL SELECT dinâmico em Pl/PgSQL
Já estudei o EXECUTE antes de postar a pergunta. Não encontrei um meio de colocar o nome da tabela e o nome da coluna de forma dinâmica, apenas os valores. Como disse anteriormente, preciso passar o nome da tabela (FROM) e o nome da coluna como parâmetros da função, assim como o seu valor. -- ** Tiago J. Adami http://www.adamiworks.com ** 2009/9/30 Roberto Mello roberto.me...@gmail.com 2009/9/30 Tiago Adami adam...@gmail.com: iValorALIAS FOR $3; BEGIN -- E aqui, o que fazer??? -- SELECT cNomeColuna FROM cNomeTabela WHERE cNomeColuna = iValor; corte Pergunta: Há como executar um SQL SELECT de forma dinâmica dentro da função que possa retornar um valor? Sim, veja o EXECUTE na documentação do PL/pgSQL. Roberto ___ 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
Re: [pgbr-geral] Performance usando funções em PLP GSQL comparadas ao PL/SQL no Oracle
Márcio, Tenho vários programas em PL/SQL compostos por milhares de linhas, que efetuam uma série de cálculos, utizando, inclusive, de recursividade, e gostaria de portá-los para o Post. Infelizmente, na versão 8.2.7, tais ficaram extremamente lentos, inviabilizando uma das etapas do projeto. Não cheguei a testar em nenhuma outra versão. Este me parece um caso bem especial onde uma das limitações do Postgres quanto a desempenho fica radicalmente amplificada. O Postgres não armazena o código compilado das suas stored procedures ou functions, obrigando-se a recompilar e reinterpretar o código com muito mais frequência do que o Oracle. Enquanto o Postgres não armazenar algum código intermediário (como o Oracle e o SQL Server, por exemplo), não vejo nenhuma chance do seu projeto se tornar viável em Postgres sem um investimento radical e praticamente injustificável de reescrever estas funções em C. Atenciosamente, Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SQL SELECT dinâmico em Pl/PgSQL
Obrigado, Fabrízio. Gostaria de fazer mais duas perguntas a respeito da sua resposta: 1) Existem duas funções EXECUTE no PostgreSQL? Estive consultando a documentação em [1] e pelo o que entendi, é apenas para códigos preparados (prepared statements); 2) A função agora ficou assim: CREATE OR REPLACE FUNCTION f_valor_existe( VARCHAR, VARCHAR, INTEGER ) RETURNS BOOLEAN AS $f_valor_existe$ DECLARE cNomeTabelaALIAS FOR $1; cNomeColunaALIAS FOR $2; iValorALIAS FOR $3; cSQLTEXT; nIDINTEGER; BEGIN cSQL = 'SELECT '||cNomeColuna||' FROM '||cNomeTabela||' WHERE '||cNomeColuna || ' = ' || CAST(iValor AS TEXT); RAISE INFO 'Comando SQL: %', cSQL; EXECUTE cSQL; IF FOUND THEN return true; END IF; RETURN false; END; $f_valor_existe$ LANGUAGE 'plpgsql' VOLATILE; Compila e executa perfeitamente. Mas mesmo existindo o valor na tabela, o resultado de FOUND sempre é FALSE. Alguma sugestão para contornar este comportamento? Obrigado mais uma vez. [1] http://www.postgresql.org/docs/8.4/static/sql-execute.html -- ** Tiago J. Adami http://www.adamiworks.com ** 2009/9/30 Fabrízio de Royes Mello fabriziome...@gmail.com 2009/9/30 Tiago Adami adam...@gmail.com Já estudei o EXECUTE antes de postar a pergunta. Não encontrei um meio de colocar o nome da tabela e o nome da coluna de forma dinâmica, apenas os valores. Como disse anteriormente, preciso passar o nome da tabela (FROM) e o nome da coluna como parâmetros da função, assim como o seu valor. Quem sabe algo parecido com: EXECUTE 'SELECT '||cNomeColuna||' FROM '||cNomeTabela||' WHERE '||cNomeColuna =' || CAST(iValor AS TEXT); Cordialmente, -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.com ___ 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
Re: [pgbr-geral] Duvidas quanto ao desempenho
Exatamente, são sim tabelas de "testes", geramos dados para ferramentas de pesquisa a partir de outros dados antigos... Quanto ao explain eu também já rodei sim, mas achei o modelo "correto" normalmente usando os índices conforme esperado, alías os únicos indices nessas tabelas são mesmo os que eu disse, tem um índice em set08 p/ "NUM_INST" e outro na tabela consumo para o "num_instala", apenas estes.. Na verdade nós podemos operar "fora" do banco de dados, fazer esses updates fora e depois levar para o banco, mas estavamos exatamente testando manter todas as operações no banco e esbarramos nesses tempos aí...Já rodamos analyse sim, vaccum depois de alterações mais pesadas e etc.. o desempenho melhorou um pouco depois disso, mais ainda sim experimentamos aqueles tempos que disse no primeiro post.. mas vou experimentar rodar o analyse novamente e testar para ver..Estou enviando o arquivo .conf hospedado no TextBin : textbin.com/1801lObrigado pela atenção pessoal..Em 30/09/2009 08:24, Jose adriano Alves alves.jadri...@gmail.com escreveu: Meu amigo...Só uma dúvida...Que tipo de tabela é essa que vc está dando update? Não sistema real e sim testes, certo???Outra coisa... Você já rodou um EXPLAIN para saber como está sendo feito esse update?A pulga que está atrás da orelha é: Como assim atualizar milhões de registros?? 2009/9/30 Rafael Domiciano rafael.domici...@gmail.com Você poderia postar pra nós o seu arquivo .conf, assim saberemos o que foi modifcado, e também os índices dessas tabelas. 2009/9/30 Jose adriano Alves alves.jadri...@gmail.com Voce ja rodou algum "analise" no banco?? 2009/9/29 crgpww crg...@bol.com.br Olá pessoal, sou novo na lista e estamos começando a trabalhar a pouco tempo com o pg.. Estamos com um volume grande de dados e naturalmente estamos levando bastante tempo para operar com as tabelas, no entanto estamos achando que o desempenho está muito abaixo do esperado ou normal.. Situações que ilustram bem o que está acontecendo são as as seguintes atualizações... UPDATE public.set08 SET hcons1 = c.campo46, hcons2 = c.campo47, . . . hcons24 = c.set_2008_kwhFROM consumo cWHERE "NUM_INST" = c.num_instala; Esta operação tem levado em média 20 horas sem mais nenhuma operação acontecendo em paralelo no banco... se houver o desempenho piora pra pelo menos mais 4 horas.. Nesta tabela que está sofrendo update ao todo sao 115 colunas com 5,5 milhões de registros, que representam cerca de 2,5 gb de dados num arquivo texto... A tabela "consumo" é constiuida de 75 colunas de numeros inteiros, tem 4 milhões de registros aproximadamente, existindo um indice para num_instala. Nas tabelas que sofrem a operação, nesse caso "set08" não há indice sobre NUM_INST, com o índice o desempenho piorou em 4 horas praticamente... O segundo update é muito mais simples mas demora demais também, cerca de 6 horas. UPDATE set08SET hcons19 = 0 where hcons19 is null; Lendo algumas outras listas e conversando com amigos mais experientes em PG eles me sugeriram pequenas alterações no arquivo .conf, no sentido de aumentar memória e cache mas tais mudanças nao ajudaram em nada o desempenho.. O S. O. é Windows XP Professional com Sp3, e o PostgreSQL é versão 8.3... A Márquina é um Intel Core 2 Quad 2.83Ghz com 3 GB de RAM... Vocês poderiam me dizer se estes tempos de execução estão normais? A expectativa era que o desempenho seria bem melhor.. o que poderia ser feito para melhorar? Abraço e Obrigado, Gustavo. ___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att.José Adriano AlvesAnalista de Sistemas - Móveis Gazin.Cel..: +55 44 8802 3994Fone: + 55 44 3663 8000 - 2319Mail: alves.jadri...@gazin.com.brMSN: jose.adri...@gazin.com.brEste e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signat ário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN.Antes de imprimir pense em seu compromisso com o Meio Ambiente___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att.José Adriano AlvesAnalista de Sistemas - Móveis
Re: [pgbr-geral] SQL SELECT dinâmico em Pl/PgSQL
Achei a documentação. Estava tão obcecado pelo EXECUTE que entrei no lugar
errado da documentação. Talvez pudesse existir um link para [2] dentro da
documentação do comando EXECUTE.
Agora sim está funcionando perfeitamente. A versão final da função ficou:
CREATE OR REPLACE FUNCTION f_valor_existe( VARCHAR, VARCHAR, INTEGER )
RETURNS BOOLEAN AS
$f_valor_existe$
DECLARE
cNomeTabelaALIAS FOR $1;
cNomeColunaALIAS FOR $2;
iValorALIAS FOR $3;
cSQLTEXT;
nCountINTEGER;
BEGIN
cSQL = 'SELECT COUNT('||cNomeColuna||') AS _ID FROM '||cNomeTabela||'
WHERE '||cNomeColuna || ' = ' || CAST(iValor AS TEXT);
RAISE INFO 'Comando SQL: %', cSQL;
EXECUTE cSQL INTO nCount;
IF nCount 0 THEN
return true;
END IF;
RETURN false;
END;
$f_valor_existe$
LANGUAGE 'plpgsql' VOLATILE;
[2]
http://www.postgresql.org/docs/8.4/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN
--
**
Tiago J. Adami
http://www.adamiworks.com
**
2009/9/30 Tiago Adami adam...@gmail.com
Obrigado, Fabrízio. Gostaria de fazer mais duas perguntas a respeito da sua
resposta:
1) Existem duas funções EXECUTE no PostgreSQL? Estive consultando a
documentação em [1] e pelo o que entendi, é apenas para códigos preparados
(prepared statements);
2) A função agora ficou assim:
CREATE OR REPLACE FUNCTION f_valor_existe( VARCHAR, VARCHAR, INTEGER )
RETURNS BOOLEAN AS
$f_valor_existe$
DECLARE
cNomeTabelaALIAS FOR $1;
cNomeColunaALIAS FOR $2;
iValorALIAS FOR $3;
cSQLTEXT;
nIDINTEGER;
BEGIN
cSQL = 'SELECT '||cNomeColuna||' FROM '||cNomeTabela||' WHERE
'||cNomeColuna || ' = ' || CAST(iValor AS TEXT);
RAISE INFO 'Comando SQL: %', cSQL;
EXECUTE cSQL;
IF FOUND THEN
return true;
END IF;
RETURN false;
END;
$f_valor_existe$
LANGUAGE 'plpgsql' VOLATILE;
Compila e executa perfeitamente. Mas mesmo existindo o valor na tabela, o
resultado de FOUND sempre é FALSE. Alguma sugestão para contornar este
comportamento?
Obrigado mais uma vez.
[1] http://www.postgresql.org/docs/8.4/static/sql-execute.html
--
**
Tiago J. Adami
http://www.adamiworks.com
**
2009/9/30 Fabrízio de Royes Mello fabriziome...@gmail.com
2009/9/30 Tiago Adami adam...@gmail.com
Já estudei o EXECUTE antes de postar a pergunta. Não encontrei um meio de
colocar o nome da tabela e o nome da coluna de forma dinâmica, apenas os
valores. Como disse anteriormente, preciso passar o nome da tabela (FROM) e
o nome da coluna como parâmetros da função, assim como o seu valor.
Quem sabe algo parecido com:
EXECUTE 'SELECT '||cNomeColuna||' FROM '||cNomeTabela||' WHERE
'||cNomeColuna =' || CAST(iValor AS TEXT);
Cordialmente,
--
Fabrízio de Royes Mello
Blog sobre TI: http://fabriziomello.blogspot.com
___
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
Re: [pgbr-geral] SQL SELECT dinâmico em Pl/PgSQL
2009/9/30 Tiago Adami adam...@gmail.com Obrigado, Fabrízio. Gostaria de fazer mais duas perguntas a respeito da sua resposta: 1) Existem duas funções EXECUTE no PostgreSQL? Estive consultando a documentação em [1] e pelo o que entendi, é apenas para códigos preparados (prepared statements); É isso ai... dentro de uma PL/PgSQL o EXECUTE tem uma função [1] e no que diz respeito a Prepared Statments tem outra função [2]. corte Compila e executa perfeitamente. Mas mesmo existindo o valor na tabela, o resultado de FOUND sempre é FALSE. Alguma sugestão para contornar este comportamento? O EXECUTE não atualiza a variável especial FOUND numa PL/PgSQL, veja em [3] quando a variável FOUND é atualizada. Mas você pode reescrever a tua PL da seguinte maneira para atender o requisito: CREATE OR REPLACE FUNCTION f_valor_existe( VARCHAR, VARCHAR, INTEGER ) RETURNS BOOLEAN AS $f_valor_existe$ DECLARE cNomeTabelaALIAS FOR $1; cNomeColunaALIAS FOR $2; iValor ALIAS FOR $3; cSQL TEXT; lRetorno BOOLEAN DEFAULT false; BEGIN cSQL := 'SELECT EXISTS(SELECT 1 FROM '||cNomeTabela||' WHERE '||cNomeColuna || ' = ' || CAST(iValor AS TEXT)||')'; RAISE INFO 'Comando SQL: %', cSQL; EXECUTE cSQL INTO lRetorno; RETURN lRetorno; END; $f_valor_existe$ LANGUAGE 'plpgsql' VOLATILE; [1] http://www.postgresql.org/docs/8.4/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN [2] http://www.postgresql.org/docs/8.4/static/sql-execute.html [3] http://www.postgresql.org/docs/8.4/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS Cordialmente, -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Correçao error de cast
Olha pessoal, recentemente fiz ums testes na versao 8.3 do postgres é costatei um erro com referencia ao cast explicito. select case substr(AnoMes::text,5,2) WHEN 12 THEN AnoMes+89 ELSE AnoMes+1 END AnoMes = integer ERROR: operator does not exist: text = integer HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. apos rodar a gabiarra da volta dos casts automaticos ele roda BLZ,como faço pra rodar essas query sem este artificio e assim manter o padrao da 8.3 em diante? agradeço a todos Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Aumentar Número de Indices por Tabe la
Olá pessoal, Gostaria de pedir a ajuda de vocês, estou precisando aumentar o meu número de indices por tabela, que por default aceita no máximo 32 indexações. Obrigado pela atenção e aguardo dicas. vlw -- Fernando Maia Acadêmico Sistemas de Informação-CPCX-UFMS msn: maia_...@hotmail.com email: maia...@gmail.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] Correçao error de cast
2009/9/30 paulo matadr saddon...@yahoo.com.br: Olha pessoal, recentemente fiz ums testes na versao 8.3 do postgres é costatei um erro com referencia ao cast explicito. select case substr(AnoMes::text,5,2) WHEN 12 THEN AnoMes+89 ELSE AnoMes+1 Creio que o erro está em WHEN 12, deveria ser WHEN '12', afinal é um string. END AnoMes = integer ERROR: operator does not exist: text = integer Olhe aí: está tentando comparar um texto (o resultado da função substr) com um inteiro (12) HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. apos rodar a gabiarra da volta dos casts automaticos ele roda BLZ,como faço pra rodar essas query sem este artificio e assim manter o padrao da 8.3 em diante? Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Res: Correçao error de cast
Era isso mesmo , Vlw De: Osvaldo Kussama osvaldo.kuss...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Quarta-feira, 30 de Setembro de 2009 17:47:31 Assunto: Re: [pgbr-geral] Correçao error de cast 2009/9/30 paulo matadr saddon...@yahoo.com.br: Olha pessoal, recentemente fiz ums testes na versao 8.3 do postgres é costatei um erro com referencia ao cast explicito. select case substr(AnoMes::text,5,2) WHEN 12 THEN AnoMes+89 ELSE AnoMes+1 Creio que o erro está em WHEN 12, deveria ser WHEN '12', afinal é um string. END AnoMes = integer ERROR: operator does not exist: text = integer Olhe aí: está tentando comparar um texto (o resultado da função substr) com um inteiro (12) HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. apos rodar a gabiarra da volta dos casts automaticos ele roda BLZ,como faço pra rodar essas query sem este artificio e assim manter o padrao da 8.3 em diante? Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.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] Aumentar Número de Indices por Tabe la
Fernando Maia escreveu: Gostaria de pedir a ajuda de vocês, estou precisando aumentar o meu número de indices por tabela, que por default aceita no máximo 32 indexações. Você está querendo ter mais do que 32 índices em uma tabela? Há algo errado com o seu modelo de dados, não? Em todo caso, você precisará recompilar o PostgreSQL após alterar o parâmetro INDEX_MAX_KEYS no arquivo src/include/pg_config_manual.h. Além disso, você precisará executar o initdb novamente, ou seja, terá que fazer uma cópia de segurança (aka _dump_) e uma restauração (aka _restore_). -- 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] DataWarehouse
obrigado Alcione. to buscando informação. 2009/9/29 Alcione Benacchio benacc...@gmail.com Olá Gustavo, Também estou buscando informações a respeito. Descobri um tal de Bizgres, que não consegui fazer download ainda e também não sei se é bom. Att. Alcione 2009/9/23 Marcelo Costa marcelojsco...@gmail.com Olá Gustavo 2009/9/22 Gustavo Lobato gustavo.lob...@gmail.com Gostaria de saber quais ferramentas free estão disponíveis para o uso de BI no postgres, no caso, um simples datawarehouse para meu projeto de conclusão de curso. alguém para me orientar quanto a isso? Pesquise sobre o Pentaho, há uma lista dele. http://br.groups.yahoo.com/group/pentahobr/ Não esqueça de alterar as strings de conexão para o PostgreSQL Atte, -- Marcelo Costa www.marcelocosta.net - “You can't always get what want”, Doctor House in apology to Mike Jagger ___ 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Duvidas quanto ao desempenho
2009/9/30 crgpww crg...@bol.com.br: Já rodamos analyse sim, vaccum depois de alterações mais pesadas e etc.. o desempenho melhorou um pouco depois disso, mais ainda sim experimentamos aqueles tempos que disse no primeiro post.. mas vou experimentar rodar o analyse novamente e testar para ver.. Estou enviando o arquivo .conf hospedado no TextBin : textbin.com/1801l HORRIVEL esse textbin. Favor postar num lugar em que dê para ler o arquivo, tal como o pastebin. Não li todo o arquivo por que não tive paciência de ficar decifrando o textbin, mas parece que seu shared_buffers tá muito alto, seu work_mem e sort_mem estão muito baixos. Roberto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Duvidas quanto ao desempenho
Ok, desculpe.. http://pastebin.com/m458e25f5 E obrigado pela dica ! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] DataWarehouse
2009/9/29 Alcione Benacchio benacc...@gmail.com: Descobri um tal de Bizgres, que não consegui fazer download ainda e também não sei se é bom. Este Bizgres foi patrocinado pela Greenplum[1] A versão comercial é chamada de Greenplum Database e está na versão 3.3[2] Na página da versão comercial existe um link para se registrar e assim poder fazer o download dos produtos. Após se registrar e fazer o login, é só ir na área de downloads e lá terá o Bizgres na ultima versão 0.9. [1] http://www.greenplum.com/ [2] http://www.greenplum.com/products/greenplum-database/ -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Olá Euler, a resposta é sim preciso de mais de 32 indices em uma tabela, no caso estou desenvolvendo um data warehouse, e minha tabela fato tera mais de 32 dimensões, o por isso de fazer essa modificação. Eu sei dessa alteração no pg_config_manual.h, mas não sei se fiz certo... o que eu fiz foi o seguinte: baixei o postgres.tar.gz alterei o pg_config_manual.h e compilei e instalei o postgres... mas não resolveu meu problema. Será que fiz da forma correta? Agradeço a atenção 2009/9/30 Euler Taveira de Oliveira eu...@timbira.com Fernando Maia escreveu: Gostaria de pedir a ajuda de vocês, estou precisando aumentar o meu número de indices por tabela, que por default aceita no máximo 32 indexações. Você está querendo ter mais do que 32 índices em uma tabela? Há algo errado com o seu modelo de dados, não? Em todo caso, você precisará recompilar o PostgreSQL após alterar o parâmetro INDEX_MAX_KEYS no arquivo src/include/pg_config_manual.h. Além disso, você precisará executar o initdb novamente, ou seja, terá que fazer uma cópia de segurança (aka _dump_) e uma restauração (aka _restore_). -- 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 -- Fernando Maia Acadêmico Sistemas de Informação-CPCX-UFMS msn: maia_...@hotmail.com email: maia...@gmail.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] Aumentar Número de Indices por Tabe la
2009/9/30 Fernando Maia maia...@gmail.com: Eu sei dessa alteração no pg_config_manual.h, mas não sei se fiz certo... o que eu fiz foi o seguinte: baixei o postgres.tar.gz alterei o pg_config_manual.h e compilei e instalei o postgres... mas não resolveu meu problema. Então colega, se você baixo o Postgres, alterou o arquivo pg_config_manual.h depois configurou, compilou, instalou e criou o cluster com initdb, não deveria dar problemas. Eu recomendo dar uma revisada nos passos que você seguiu. Se você já tiver feito as operações acima sem antes ter alterado o pg_config, você vai precisar configurar, compilar, instalar e criar um novo cluster com o initdb. Os comandos abaixo para criar uma tabela e um índice com 40 colunas deu certo: drop table if exists teste; create table teste ( cola integer not null, colb integer not null, colc integer not null, cold integer not null, cole integer not null, colf integer not null, colg integer not null, colh integer not null, coli integer not null, colj integer not null, colk integer not null, coll integer not null, colm integer not null, coln integer not null, colo integer not null, colp integer not null, colq integer not null, colr integer not null, cols integer not null, colt integer not null, colu integer not null, colv integer not null, colw integer not null, colx integer not null, coly integer not null, colz integer not null, cola2 integer not null, colb2 integer not null, colc2 integer not null, cold2 integer not null, cole2 integer not null, colf2 integer not null, colg2 integer not null, colh2 integer not null, coli2 integer not null, colj2 integer not null, colk2 integer not null, coll2 integer not null, colm2 integer not null, coln2 integer not null, colo2 integer not null, colp2 integer not null, colq2 integer not null, colr2 integer not null, cols2 integer not null, colt2 integer not null, colu2 integer not null, colv2 integer not null, colw2 integer not null, colx2 integer not null, coly2 integer not null, colz2 integer not null); create index teste_idx on teste using btree ( cola, colb, colc, cold, cole, colf, colg, colh, coli, colj, colk, coll, colm, coln, colo, colp, colq, colr, cols, colt, colu, colv, colw, colx, coly, colz, cola2, colb2, colc2, cold2, cole2, colf2, colg2, colh2, coli2, colj2, colk2, coll2, colm2, coln2); -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Tarcísio Sassara escreveu: Os comandos abaixo para criar uma tabela e um índice com 40 colunas deu certo: Ele não quer criar um índice de 40 colunas e sim 40 índices em uma tabela. -- 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] Aumentar Número de Indices por Tabe la
exato... na realidade preciso fazer isso: create table fato( coluna01 integer, coluna02 integer, coluna03 integer, . . . coluna50 integer, PRIMARY KEY(coluna01,coluna02,coluna03...coluna50) ); 2009/9/30 Euler Taveira de Oliveira eu...@timbira.com Tarcísio Sassara escreveu: Os comandos abaixo para criar uma tabela e um índice com 40 colunas deu certo: Ele não quer criar um índice de 40 colunas e sim 40 índices em uma tabela. -- 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 -- Fernando Maia Acadêmico Sistemas de Informação-CPCX-UFMS msn: maia_...@hotmail.com email: maia...@gmail.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] Aumentar Número de Indices por Tabe la
2009/9/30 Euler Taveira de Oliveira eu...@timbira.com: Ele não quer criar um índice de 40 colunas e sim 40 índices em uma tabela. 1: Foi mals. Acho que não entendi/li direito. =D 2: Nunca vi isso. Em um DW eu coloco na tabela fato as chaves estrangeiras de cada dimensão e coloco apenas um índice contendo todas estas chaves. E de qualquer maneira, a constante INDEX_MAX_KEYS encontrada no pg_config_manual se refere a quantidade maxíma de colunas em um índice e não a quantidade de índices por tabela. -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
2009/9/30 Fernando Maia maia...@gmail.com: exato... na realidade preciso fazer isso: create table fato( coluna01 integer, coluna02 integer, coluna03 integer, . . . coluna50 integer, PRIMARY KEY(coluna01,coluna02,coluna03...coluna50) ); Opá, opá. Então, da uma olhada lá no arquivo pg_config_manual. O único detalhe sobre performance é colocar um número múltiplo de 32. Talvez 64 resolva, não? E siga tudo do começo: configura, compila, instala e cria o cluster com initdb. Abraço. -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Eu escrevi: Tarcísio Sassara escreveu: Os comandos abaixo para criar uma tabela e um índice com 40 colunas deu certo: Ele não quer criar um índice de 40 colunas e sim 40 índices em uma tabela. Opsss... [Faltando cafeína a essa hora da noite] É isso mesmo. Índice com 40 colunas. -- 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] Aumentar Número de Indices por Tabe la
Fernando Maia escreveu: Será que fiz da forma correta? Você tem que executar o initdb novamente para criar outro _cluster_. -- 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] Aumentar Número de Indices por Tabe la
Olá pessoal, Eu gostaria de discutir isso com vcs: Em um DW eu coloco na tabela fato as chaves estrangeiras de cada dimensão e coloco apenas um índice contendo todas estas chaves. esse DW é um trabalho da universidade, minha tutora ensiste em dizer que a fato deve ser criada daquela forma, segundo ela, faz parte do modelo lógico da tabela fato a criação de todas as dimensões como primary key. 2009/9/30 Euler Taveira de Oliveira eu...@timbira.com Fernando Maia escreveu: Será que fiz da forma correta? Você tem que executar o initdb novamente para criar outro _cluster_. -- 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 -- Fernando Maia Acadêmico Sistemas de Informação-CPCX-UFMS msn: maia_...@hotmail.com email: maia...@gmail.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] Aumentar Número de Indices por Tabe la
2009/10/1 Fernando Maia maia...@gmail.com: esse DW é um trabalho da universidade, minha tutora ensiste em dizer que a fato deve ser criada daquela forma, segundo ela, faz parte do modelo lógico da tabela fato a criação de todas as dimensões como primary key. Mas Fernando, está correto. Estas colunas identificam um registro na tabela fato. Explicando um pouco melhor: O banco de dados de produção, ou seja, aquele que é utilizado pela aplicação do cliente deve ser separado do banco que será o Data Warehouse. Não da para usar um mesmo modelo para as duas coisas: Produção e Análise. Primeiro vem o banco produção onde você vai criar todas as tabelas com as chaves primarias e estrangeiras, índices e se possível, seguindo as formas normais. Depois vem o banco warehouse que deve conter uma estrutura especifica para este problema. Uma dica para o warehouse que tem muitas dimensões é ver se você não está colocando 2 vezes a mesma dimensão. Ex: Uma coluna apontando para uma dimensão ano e outra apontando para mês, quando o correto seria uma única referência para uma dimensão chamada data. Depois você deve criar um script que transforma e envia os dados do banco produção para o banco warehouse. Claro, se você estiver carregando os dados vindos de um arquivo de texto, você não terá um banco em produção. Somente terá o warehouse. Eu lhe recomendo um livro muito bom: The Data Warehouse Toolkit (Ralph Kimball) http://www.amazon.com/exec/obidos/ASIN/0471200247/ralphkimballc-20/104-5050702-4100704 Abraço! -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
