Re: [pgbr-geral] Sem Memória para executar uma fun ção
Em Ter, 2007-07-24 às 21:17 -0300, Euler Taveira de Oliveira escreveu: > Leandro Guimarães Faria Corcete DUTRA wrote: > > > E por que não viria a estar? Faz parte do ISO SQL:2003, senão mesmo de > > versões mais antigas. > > > Interesse de algum desenvolvedor é uma boa resposta? Quem sabe daqui > algumas versões... Don't hold your breath! Tenho visto bastante intereße, mas não fui a fundo. De qualquer maneira, creio que as implementações atuais já ajudem bastante. -- Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sem Memória para executar uma fun ção
Leandro Guimarães Faria Corcete DUTRA wrote: > E por que não viria a estar? Faz parte do ISO SQL:2003, senão mesmo de > versões mais antigas. > Interesse de algum desenvolvedor é uma boa resposta? Quem sabe daqui algumas versões... Don't hold your breath! -- 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] Sem Memória para executar uma fun ção
Em Ter, 2007-07-24 às 10:58 -0300, Welington R. Braga escreveu: > A intenção é essa. Mas a coisa não é tão fácil assim, pois a aplicação > é muito grande e qualquer alteração deve ser feita devagar e > testando-se para não afetar os demais módulos que já funcionam (não > falem pra ninguém que fui eu quem disse, mas ela é um conjunto de > gambiarras que funcionava quando a coisa era menor) ;-) . Solidarizo-me com tua dor… mas creio que talvez valha a pena pagar por um bom consultor de desempenho. Há alguns na lista, vêm à mente o Telles, o Ike, o Leonardo… desculpem-me os que esqueci. -- Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sem Memória para executar uma fun ção
Em 24/07/07, Leandro Guimarães Faria Corcete DUTRA<[EMAIL PROTECTED]> escreveu: > Em Ter, 2007-07-24 às 10:12 -0300, Welington R. Braga escreveu: > > É uma aplicação que processa certos dados científicos e depois os > > disponibiliza via WEB para uma outra instituição. Na realidade eu me > > expressei errado aqui, a visão PROCESSA um volume de dados na ordem > > dos 400.000.000 registros, mas na realidade só RETORNA 2.000.000 ou > > algo próximo disso. > > Hm… talvez seja o caso de, além de usar visões materializadas ou mesmo > alternativamente a elas, otimizar o SQL e (ou) a estrutura? A intenção é essa. Mas a coisa não é tão fácil assim, pois a aplicação é muito grande e qualquer alteração deve ser feita devagar e testando-se para não afetar os demais módulos que já funcionam (não falem pra ninguém que fui eu quem disse, mas ela é um conjunto de gambiarras que funcionava quando a coisa era menor) ;-) . > > Sendo via Web, não pode ser sob demanda? Aí as visões aumentam a > praticidade da coisa, simplesmente evitando processamentos > desnecessários porque aquela extração acaba não sendo consultada… Se ela divesse sido concebida por um analista e com o apoio de um bom DBA poderia ser sob demanda sim. Mas quando se trata de um rascunho escrito por biólogos que acham que sabem programar e depois tem que ser usada ai a coisa complica. > > > > Como eu disse é uma aplicação cientifica e em alguns pontos há > > algoritmos de processamento de árvore e mais um monte de JOIN que no > > final retornam um imenso "tabelão" que é posteriormente é transferido > > para um outro servidor via WEB. > > Não se transferem 2M de tuplas pela Teia… você quis dizer a Rede? Mesmo comentário acima. > > -- > Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> > Atech Fundação Aplicação de Tecnologias Críticas SP, BR > msnim:[EMAIL PROTECTED] > skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 > > > - - - - - > > Politica de Privacidade: Esta mensagem pode conter informacao confidencial > e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a > receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela > contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu > esta mensagem por engano, por favor avise imediatamente o remetente, > respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. > > Privacy Policy: This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > ___ > 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] Sem Memória para executar uma fun ção
Em Ter, 2007-07-24 às 10:12 -0300, Welington R. Braga escreveu: > É uma aplicação que processa certos dados científicos e depois os > disponibiliza via WEB para uma outra instituição. Na realidade eu me > expressei errado aqui, a visão PROCESSA um volume de dados na ordem > dos 400.000.000 registros, mas na realidade só RETORNA 2.000.000 ou > algo próximo disso. Hm… talvez seja o caso de, além de usar visões materializadas ou mesmo alternativamente a elas, otimizar o SQL e (ou) a estrutura? Sendo via Web, não pode ser sob demanda? Aí as visões aumentam a praticidade da coisa, simplesmente evitando processamentos desnecessários porque aquela extração acaba não sendo consultada… > Como eu disse é uma aplicação cientifica e em alguns pontos há > algoritmos de processamento de árvore e mais um monte de JOIN que no > final retornam um imenso "tabelão" que é posteriormente é transferido > para um outro servidor via WEB. Não se transferem 2M de tuplas pela Teia… você quis dizer a Rede? -- Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sem Memória para executar uma fun ção
Em 23/07/07, Euler Taveira de Oliveira<[EMAIL PROTECTED]> escreveu: > Welington R. Braga wrote: > > > O problema é que a "tabela" de onde eu executo o SELECT é uma view com > > várias tabelas e retorna um volume de dados na ordem dos 400.000.000 > > registros. > > Mas para que você quer retornar tanto registro assim? É uma aplicação que processa certos dados científicos e depois os disponibiliza via WEB para uma outra instituição. Na realidade eu me expressei errado aqui, a visão PROCESSA um volume de dados na ordem dos 400.000.000 registros, mas na realidade só RETORNA 2.000.000 ou algo próximo disso. > > > > Se eu separar esses vários conjuntos de de TRUNCATE + INSERT/SELECT em > > funções separadas e depois criar uma função principal chamando todas > > elas, resolveria o problema de falta de memória (estou apostando na > > questão do Postgresql considerar toda uma função como uma transação > > única - TALVEZ ESTEJA FALANDO BOBAGEM, confirmem se algum puder) ? > > > Transações diferentes podem aliviar o consumo de memória, mas acho que > com um SELECT com tantos registros assim você pode recair no mesmo > problema agora ou daqui um tempo. > > > Caso a ideia sugerida acima não resolver qual solução vocês me > > recomendariam? > > > É necessário saber para que você precisa de tanto dado assim para > podermos te orientar melhor. Como eu disse é uma aplicação cientifica e em alguns pontos há algoritmos de processamento de árvore e mais um monte de JOIN que no final retornam um imenso "tabelão" que é posteriormente é transferido para um outro servidor via WEB. > > -- > 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 > -- 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] Sem Memória para executar uma fun ção
Em Seg, 2007-07-23 às 17:57 -0300, Euler Taveira de Oliveira escreveu: > Leandro Guimarães Faria Corcete DUTRA wrote: > > > Não entendi, quem falou em gatilhos? A idéia é usar as visões > > materializadas e pronto… ou eles ainda são necessários na v8.1, não > > lembro dos detalhes? > > > Visão materializada (aka materialized view) não está no core do > PostgreSQL ainda. Ainda não se sabe se estará. E por que não viria a estar? Faz parte do ISO SQL:2003, senão mesmo de versões mais antigas. > As duas implementações > existentes: [1] utilizando funções PL/PgSQL e [2] utilizando > PostgreSQL::Snapshots. A segunda é mais abrangente pois pode utilizar BD > distintos. Nunca testei a opção [2] mas ela utiliza Perl. É o suficiente. -- Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sem Memória para executar uma fun ção
Welington R. Braga wrote: > O problema é que a "tabela" de onde eu executo o SELECT é uma view com > várias tabelas e retorna um volume de dados na ordem dos 400.000.000 > registros. Mas para que você quer retornar tanto registro assim? > Se eu separar esses vários conjuntos de de TRUNCATE + INSERT/SELECT em > funções separadas e depois criar uma função principal chamando todas > elas, resolveria o problema de falta de memória (estou apostando na > questão do Postgresql considerar toda uma função como uma transação > única - TALVEZ ESTEJA FALANDO BOBAGEM, confirmem se algum puder) ? > Transações diferentes podem aliviar o consumo de memória, mas acho que com um SELECT com tantos registros assim você pode recair no mesmo problema agora ou daqui um tempo. > Caso a ideia sugerida acima não resolver qual solução vocês me recomendariam? > É necessário saber para que você precisa de tanto dado assim para podermos te orientar melhor. -- 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] Sem Memória para executar uma fun ção
Leandro Guimarães Faria Corcete DUTRA wrote: > Não entendi, quem falou em gatilhos? A idéia é usar as visões > materializadas e pronto… ou eles ainda são necessários na v8.1, não > lembro dos detalhes? > Visão materializada (aka materialized view) não está no core do PostgreSQL ainda. Ainda não se sabe se estará. As duas implementações existentes: [1] utilizando funções PL/PgSQL e [2] utilizando PostgreSQL::Snapshots. A segunda é mais abrangente pois pode utilizar BD distintos. Nunca testei a opção [2] mas ela utiliza Perl. [1] http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html [2] http://cunha17.cristianoduarte.pro.br/postgresql/snapshots.en_us.php -- 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] Sem Memória para executar uma fun ção
Em Seg, 2007-07-23 às 15:00 -0300, Welington R. Braga escreveu: > é uma solução "bonita", mas cada view dessa possui o JOIN para várias > tabelas e ficaria uma coisa louca gerenciar o monte de triggers > necessarias. Só pra ter uma ideia olha só nessa consulta (que é uma > view): Não entendi, quem falou em gatilhos? A idéia é usar as visões materializadas e pronto… ou eles ainda são necessários na v8.1, não lembro dos detalhes? -- Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sem Memória para executar uma fun ção
é uma solução "bonita", mas cada view dessa possui o JOIN para várias
tabelas e ficaria uma coisa louca gerenciar o monte de triggers
necessarias. Só pra ter uma ideia olha só nessa consulta (que é uma
view):
--- CONSULTA
SELECT testemunho.numtombo, familia.nometaxon::character varying(30)
AS familia, (( SELECT
CASE
WHEN arvoretaxon.aux_genero =
arvoretaxon.aux_familia THEN NULL::character varying
ELSE genero.nometaxon
END AS nometaxon))::character varying(45) AS genero, (( SELECT
CASE
WHEN (( SELECT unidadetaxon.nivelunidtaxon
FROM jabot.unidadetaxon
WHERE unidadetaxon.codunidtaxon =
arvoretaxon.codunidtaxon)) = 140 THEN arvoretaxon.nometaxon
ELSE ( SELECT
CASE
WHEN (( SELECT unidadetaxon.nivelunidtaxon
FROM jabot.unidadetaxon
WHERE unidadetaxon.codunidtaxon =
arvoretaxon.codunidtaxon)) < 140 THEN NULL::character varying
ELSE ( SELECT parenteacima_taxon.epitetotaxon
FROM
jabot.parenteacima_taxon(arvoretaxon.codarvtaxon, 140)
parenteacima_taxon(codarvtaxon, nomecompletotaxon, nivelunidtaxon,
linhasuperior_html, linhaespecie_html, linhainfra_html, unidtaxon,
statusvalidade, epitetotaxon, autortaxon))
END AS "case")
END AS "case"))::character varying(45) AS sp, (( SELECT
CASE
WHEN (( SELECT unidadetaxon.nivelunidtaxon
FROM jabot.unidadetaxon
WHERE unidadetaxon.codunidtaxon =
arvoretaxon.codunidtaxon)) = 140 THEN arvoretaxon.autortaxon
ELSE ( SELECT
CASE
WHEN (( SELECT unidadetaxon.nivelunidtaxon
FROM jabot.unidadetaxon
WHERE unidadetaxon.codunidtaxon =
arvoretaxon.codunidtaxon)) < 140 THEN NULL::character varying
ELSE ( SELECT parenteacima_taxon.autortaxon
FROM
jabot.parenteacima_taxon(arvoretaxon.codarvtaxon, 140)
parenteacima_taxon(codarvtaxon, nomecompletotaxon, nivelunidtaxon,
linhasuperior_html, linhaespecie_html, linhainfra_html, unidtaxon,
statusvalidade, epitetotaxon, autortaxon))
END AS "case")
END AS "case"))::character varying(100) AS autorsp, (( SELECT
CASE
WHEN (( SELECT unidadetaxon.nivelunidtaxon
FROM jabot.unidadetaxon
WHERE unidadetaxon.codunidtaxon =
arvoretaxon.codunidtaxon)) > 140 THEN arvoretaxon.nometaxon
ELSE NULL::character varying
END AS "case"))::character varying(25) AS infrasp,
categoriatypus.nomecattypus::character varying(20) AS nat_typus,
arvoretaxon.aux_especie::character varying(100) AS taxoncompleto,
pais.nomeunidgeo::character varying(50) AS pais,
estado.nomeunidgeo::character varying(80) AS estado_prov, (( SELECT
CASE
WHEN unidgeopolitica.codtipounidgeo >= 5 THEN
unidgeopolitica.nomeunidgeo
ELSE NULL::character varying
END AS "case"))::character varying(50) AS cidade, (
SELECT btrim("replace"("replace"( SELECT
CASE
WHEN detacesso.coduc IS NOT NULL THEN ( SELECT
CASE
WHEN (( SELECT v_unidcons.nomepessoa
FROM jabot.v_unidcons
WHERE v_unidcons.codpessoa =
detacesso.coduc)) IS NOT NULL THEN ((( SELECT v_unidcons.nomepessoa
FROM jabot.v_unidcons
WHERE v_unidcons.codpessoa =
detacesso.coduc))::text) || ' | '::text
ELSE ( SELECT
CASE
WHEN
btrim(detacesso.aux_uc::text) = ''::text OR detacesso.aux_uc IS NULL
THEN ''::text
ELSE
btrim(detacesso.aux_uc::text) || ' | '::text
END AS "case")
END AS "case")
ELSE ( SELECT
CASE
WHEN
btrim(detacesso.aux_uc::text) = ''::text OR detacesso.aux_uc IS NULL
THEN ''::text
ELSE
btrim(detacesso.aux_uc::text) || ' | '::text
END AS "case")
END AS "ca
Re: [pgbr-geral] Sem Memória para executar uma fun ção
Em Seg, 2007-07-23 às 12:42 -0300, Welington R. Braga escreveu: > Na realidade eu não sei afirmar com precisão se, em caso de substituir > tudo por uma visão, há a necessidade delas serem materializadas A idéia da materialização é poder trabalhar somente com o δ dos dados, em vez de trazer tudo toda vez. Isso dito, a última vez que mexi com isso foi no Oracle 8, não sei como está no PostgreSQL. -- Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sem Memória para executar uma fun ção
Talvez sim! Mas o negócio é que o sistema ele foi feito usando essa gambiarra e até estava funcionando bem até algum tempo atrás quando passou por um estágio de alimentação de dados mais agressiva em que contratamos alguns digitadores para fazer a digitação. Não sei se visões materializadas seriam adequadas para esse caso, visto que não conheço a fundo o sistema. Mas talvez conversando com meia dúzia de pessoas consiga convencê-las a fazermos um teste dessa forma. Mas ai entra em outra questão ... como eu faria isso no Postgresql 8.1 ?! Até o pouco que eu sei o PostgreSQL não suporta visões materializadas nativamente então teriamos que usar gambiarras para isso, certo? Existe uma forma simples de implementar isso, alguém tem algum tutorial pra indicar (o manual do postgresql apresenta algo sobre isso? Acho que já procurei sobre isso lá e não me recordo de tê-lo encontrado. Terei que ver outra vez) Antes que a galera sugira, eu já passei no Google e achei isso: [1] http://cunha17.cristianoduarte.pro.br/postgresql/snapshots.php [2] http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html Na realidade eu não sei afirmar com precisão se, em caso de substituir tudo por uma visão, há a necessidade delas serem materializadas, uma vez que estes dados são lidos por um sistema WEB rodando em algum outro servidor que não está sob os meus cuidados e só Deus sabe em que país está ele e converte tudo para XML. Vá entender o por que !!! ;-) Em todo caso eu verei mais sobre as 'materialized views' e veremos no que dá. Em 23/07/07, Leandro Guimarães Faria Corcete DUTRA<[EMAIL PROTECTED]> escreveu: > Em Seg, 2007-07-23 às 11:06 -0300, Welington R. Braga escreveu: > > Preciso rodar uma função que contém cerca de uns 5 "TRUNCATE" e > > seguidos de um respectivo "INSERT/SELECT". > > > > O problema é que a "tabela" de onde eu executo o SELECT é uma view com > > várias tabelas e retorna um volume de dados na ordem dos 400.000.000 > > registros. > > Será que você não precisa de visões materializadas? Assim talvez você > pudesse evitar essa custosa reconstrução de estruturas redundantes, > mantendo-as automaticamente. > > > -- > Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> > Atech Fundação Aplicação de Tecnologias Críticas SP, BR > msnim:[EMAIL PROTECTED] > skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 > > > - - - - - > > Politica de Privacidade: Esta mensagem pode conter informacao confidencial > e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a > receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela > contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu > esta mensagem por engano, por favor avise imediatamente o remetente, > respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. > > Privacy Policy: This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > ___ > 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] Sem Memória para executar uma fun ção
Em Seg, 2007-07-23 às 11:06 -0300, Welington R. Braga escreveu: > Preciso rodar uma função que contém cerca de uns 5 "TRUNCATE" e > seguidos de um respectivo "INSERT/SELECT". > > O problema é que a "tabela" de onde eu executo o SELECT é uma view com > várias tabelas e retorna um volume de dados na ordem dos 400.000.000 > registros. Será que você não precisa de visões materializadas? Assim talvez você pudesse evitar essa custosa reconstrução de estruturas redundantes, mantendo-as automaticamente. -- Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
