Re: [pgbr-geral] 1/2 off - sitema de arquivos linux

[Welington R. Braga]

Bom,

As três últimas vezes que montei o meu servidor PostgreSQL foram com o
ReiserFS e não tive problemas. O motivo das reinstalações foram
problemas de hardware e não de software. Devido as suas "citadas
oscilações de força"  que por lá eram frequentes os discos iam pras
"cucuias", forçando-me a reinstalar em outro, mas todas as outras
vezes em que o servidor foi derrubado devido a isso o banco levantou
novamente extremamente estável e sem qualquer problemas maiores.

2009/2/18 Eduardo :
> Jota,
>
> Estou levantando essa questão, pois não trabalho muito com "infra",
> Administro sistemas de gestão, e recentemente tive problemas com um
> servidor SuSe que sofreu a famosa queda de força, configurado com
> RaiserFS, depois de 5 horas conseguimos levantar o servidor e agora
> parece que esta estável.
>
> Estou apenas preocupado, pois sempre ouvi falar que o RaiserFS não é o
> mais indicado em instalações onde oscilações de força são recorrentes,
> por isso miha duvida...
>
> Vou estudar o XFS, mais alguma indicação?
>
> Eduardo
>
>
>
> Jota escreveu:
>> Olá,
>>
>> É uma boa pergunta. Apenas uma correção é ReiserFS e não RaserFS. Tem
>> o XFS também que é bastante rápido.
>>
>> Depende muito do que você necessita. Por exemplo, o EXT3 não suporte
>> redimensionamento para blocos superiores a 8k e a restauração do
>> journaling é lento.
>>
>> Abraços
>>
>>
>> 2009/2/18 Eduardo :
>>
>>> Srs,
>>>
>>> Nas instalações atuais, qual sistema de arquivos os srs tem
>>> utilizado/Recomendado para uso com o banco?
>>>
>>> Ext3?
>>> RaserFS?
>>> Outro?
>>>
>>> --
>>>
>>> Eduardo
>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>>
>>
>>
>>
>>
>
>
> --
>
> Eduardo Nakamatu
> Consultor de Negócios, Instrutor ADVPL Senior
> Certificado Microsiga
> Biale ADVPL Consultoria e Treinamentos.
> FoneFax: (11) 5011-4895
> e-mail: eduardo(at)advpl(dot)com(dot)br
> www.biale.com.br
> www.advpl.com.br
>
> ___
> 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://www.welrbraga.eti.br
MSN: welrbraga[*]msn·com
Gtalk: welrbraga[*]gmail·com
Yahoo / Skype:  welrbraga
PGP Key: 0x6C7654EB
Linux User #253605

"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] 1/2 off - sitema de arquivos linux

[Gilnei M. Oliveira]

Olá

Esta é uma pergunta capciosa, há muitas coisas a considerar nisto, mas
resumindo vou só citar o meu voto estável há 2 anos: JFS...

Entretanto esta parte da infra em geral é fornecida pela empresa que já fez
suas escolhas, logo não há poder de influência neste item...

O JFS funciona bem inclusive com dm-crypt e lvm, é muto rápido e dos que
já testei é o que menos usa processador... ainda não vi uma catástrofe
que ele não sobrevivesse, mas já ouvi falar disso, igual aos demais e a qualquer
tecnologia humana... hehehe...

Ele é "antigo", está nos AIX desde 1990 e nos linux desde 2001... já
foi testado a
ferro e fogo muitas vezes... recomendo que se tu desejas avaliar
comparativamente
olhe ele também... não entrarei em detalhes técnicos, mas o google e demais
searchs são amigáveis para isto... hehehe...

bye

gilnei

PS: Dos citados ReiserFS é o HELL... pesadelos só em lembrar este
nome... arghh!!!



2009/2/18 Fábio Telles Rodriguez :
> 2009/2/18 Eduardo :
>> Srs,
>>
>> Nas instalações atuais, qual sistema de arquivos os srs tem
>> utilizado/Recomendado para uso com o banco?
>>
>> Ext3?
>> RaserFS?
>> Outro?
>>
>
> Pergunta difícil...
>
> Ao invés de uma resposta clara, algumas considerações:
>
> 1) RaiserFS não é adequado para arquivos grandes como em bancos de dados.
> 2) EXT3 é mais estável;
> 3) XFS é um pouco mais rápido;
> 4) Seja qual for o FS escolhido, se você fizer um tuning agressivo,
> utilizando writeback, noauto, etc... a segurança pode diminuir em caso
> de crash.
> 5) Particionamento agressivo, uso de RAID, separação de tablespaces e
> configurações de memória são EM GERAL mais importantes que uma longa
> discussão sobre FS.
> 6) Só mude o tamanho do bloco em casos muito expressivos como em
> aplicações OLTP puras com MUITOS usuários ATIVOS simultâneos,,(quando
> diminuir o tamanho do bloco pode ajudar um pouco) ou em aplicações de
> suporte a decisão com a maioria dos objetos ENORMES (imagine aqui
> índices com mais de 10GB como algo normal) onde aumentar o tamanho do
> bloco pode ajudar.
> 7) Uma configuração mais específica de FS em geral consegue melhorar
> 5% a 10% em algumas operações do banco e piorar de 30% a 60% em
> outras. Pense bem antes de se aventurar nisso.
>
> Em geral a minha resposta é: fique entre o EXT3 e o XFS e se preocupe
> com outras coisas mais importantes. É claro que você pode fazer uma
> combinação mais exótica como: ext2 nos tablespaces, XFS para o WAL e
> EXT3 para o resto... mas isso é muita viagem e para provar que isso ou
> outra configuração é melhor ou pior iria levar meses de testes por
> equipe muito bem qualificada...
>
> Acho que é isso, a experiência de alguém aqui na lista aponta para
> outra direção?
>
> []s
> Fábio Telles
> --
> blog: http://www.midstorm.org/~telles/
> e-mail / jabber: fabio.tel...@gmail.com
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
(pt_BR;ogil...@gmail.com)
E9BA2383; wwwkeys.pgp.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[Fabrízio de Royes Mello]

Olá,

Vc pode utilizar a coluna reltuples da pg_class:

select reltuples from pg_class where relname = 'minha_tabela';

Mas tem que rodar um ANALYZE frequentemente para ter esse valor mais próximo
da realidade.


-- 
Fabrízio de Royes Mello
>> Blog sobre PostgreSQL: 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

Re: [pgbr-geral] Paginação

[Jota]

Pessoal,

Outra opção é realizar um select na tabela pg_class pelo atributo
reltuples, assim é possível extrair a quantidade de linhas da sua
tabela. Porém, é importante executar o analyze no mínimo uma vez por
dia para ter estatísticas mais precisas.

O select é: SELECT reltuples FROM pg_class WHERE relname='nome_da_tabela';

[]s

2009/2/18 Nilson Chagas :
> Puxa vou ler sobre.
>
> []s
> Nilson Chagas - Ubuntu User 25794
> ---
> Visite:
> http://www.amados.com.br/podcast -> Peça gratuitamente um curso Bíblico
> http://tempodesalvacao.blogspot.com/
> http://bbnradio.org/ -> Ouça a rádio e faça gratuitamente um Curso Biblico
>
>
>
>
> 2009/2/18 Dickson S. Guedes 
>>
>> 2009/2/18 sergio santos :
>> > Veja bem pessoal,
>> > se eu usar o limit o método RecordCount do Adodb vai me retornar o valor
>> > limit e não o número de registro.
>> > Sendo assim, como estou fazendo uma paginação, vai ficar difícil saber o
>> > número de páginas vou ter
>> >
>> > o que vocês acham?
>>
>> Ola Sergio,
>>
>> Você precisa saber *exatamente* quantas paginas darão? Uma estimativa
>> (assim como o Google faz) já não ajudaria?
>>
>> Dependendo do tamanho desta sua tabela você pode aproveitar as
>> estatísticas do banco, ao invés de fazer um count(*) para saber o
>> total de registros e paginar.
>>
>> Faça um teste de exemplo em uma *base de teste*:
>>
>> CREATE TABLE temp (a int);
>> INSERT INTO temp SELECT generate_series(1,10);
>> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
>> ANALYZE temp;
>> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
>> INSERT INTO temp SELECT generate_series(1,2);
>> SELECT count(*) from temp;
>> ANALYZE temp;
>> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
>> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
>> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
>> SELECT count(*) from temp;
>> DROP TABLE temp;
>>
>> Veja como os resultados podem variar no caso do count a medida que o
>> volume de dados vai crescendo.
>>
>> Obviamente o script acima não contem a solução pronta, é apenas uma
>> demonstração de que é possível trabalhar com estimativas ao invés de
>> exatos, em determinadas situações.
>>
>> Para se aprofundar, leia:
>>
>> http://www.postgresql.org/docs/current/static/monitoring-stats.html
>>
>>
>> Dickson S. Guedes
>> -
>> mail/xmpp: gue...@guedesoft.net - skype: guediz
>> http://guedesoft.net - http://planeta.postgresql.org.br
>> ___
>> 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
>
>



-- 
João Paulo
www.dextra.com.br/postgres
PostgreSQL
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[Nilson Chagas]

Puxa vou ler sobre.

[]s
Nilson Chagas - Ubuntu User 25794
---
Visite:
http://www.amados.com.br/podcast -> Peça gratuitamente um curso Bíblico
http://tempodesalvacao.blogspot.com/
http://bbnradio.org/ -> Ouça a rádio e faça gratuitamente um Curso Biblico




2009/2/18 Dickson S. Guedes 

> 2009/2/18 sergio santos :
> > Veja bem pessoal,
> > se eu usar o limit o método RecordCount do Adodb vai me retornar o valor
> > limit e não o número de registro.
> > Sendo assim, como estou fazendo uma paginação, vai ficar difícil saber o
> > número de páginas vou ter
> >
> > o que vocês acham?
>
> Ola Sergio,
>
> Você precisa saber *exatamente* quantas paginas darão? Uma estimativa
> (assim como o Google faz) já não ajudaria?
>
> Dependendo do tamanho desta sua tabela você pode aproveitar as
> estatísticas do banco, ao invés de fazer um count(*) para saber o
> total de registros e paginar.
>
> Faça um teste de exemplo em uma *base de teste*:
>
> CREATE TABLE temp (a int);
> INSERT INTO temp SELECT generate_series(1,10);
> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
> ANALYZE temp;
> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
> INSERT INTO temp SELECT generate_series(1,2);
> SELECT count(*) from temp;
> ANALYZE temp;
> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
> SELECT count(*) from temp;
> DROP TABLE temp;
>
> Veja como os resultados podem variar no caso do count a medida que o
> volume de dados vai crescendo.
>
> Obviamente o script acima não contem a solução pronta, é apenas uma
> demonstração de que é possível trabalhar com estimativas ao invés de
> exatos, em determinadas situações.
>
> Para se aprofundar, leia:
>
> http://www.postgresql.org/docs/current/static/monitoring-stats.html
>
>
> Dickson S. Guedes
> -
> mail/xmpp: gue...@guedesoft.net - skype: guediz
> http://guedesoft.net - http://planeta.postgresql.org.br
> ___
> 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] Paginação

[Nilson Chagas]

Vc tá programando em que

Terminei hoje uma classe em PHP, para fazer paginação.

A unica coisa que não consegui eliminar ainda é o count(*) para saber a
quantidade total de registros.

Mas eu passo a pagina atual e a quantidade de registros por pagina, e monto
o select assim:

limit (qtd_registros_por_pagina) offset (
(pagina-1)*qtd_registros_por_pagina)


[]s
Nilson Chagas - Ubuntu User 25794
---
Visite:
http://www.amados.com.br/podcast -> Peça gratuitamente um curso Bíblico
http://tempodesalvacao.blogspot.com/
http://bbnradio.org/ -> Ouça a rádio e faça gratuitamente um Curso Biblico




2009/2/18 sergio santos 

> Veja bem pessoal,
> se eu usar o limit o método RecordCount do Adodb vai me retornar o valor
> limit e não o número de registro.
> Sendo assim, como estou fazendo uma paginação, vai ficar difícil saber o
> número de páginas vou ter
>
> o que vocês acham?
>
> 2009/2/18 José Mello Júnior 
>
>> Endendo que a questão está muito mais para a ótica de um aplicativo do que
>> para o SGBD, mas aproveitando esta dúvida eu gostaria de perguntar o
>> seguinte: em um caso como esse, é mais fácil (ou dinâmico) a manipulação de
>> um cursor, onde o postgres se preocupa com o dimensionamento do resultado ou
>> utilizando LIMIT e OFFSET as consultas são de alguma forma otimizadas?
>>
>> []´s
>>
>> 2009/2/18 Osvaldo Kussama 
>>
>>> 2009/2/18 sergio santos :
>>> >
>>> > tô me referindo a paginação em SQL
>>> > exemplo: se minha consulta retornar 1000 registros tenho que passar um
>>> > parâmetro para o banco informando que quero exibir somente os registros
>>> > entre 150 e 200 ou seja, serão exibidos 50 registro, isso de forma
>>> dinâmica
>>> > fazendo com que a minha consulta sql faça uma paginação.
>>> >
>>>
>>>
>>> Então, reafirmando o que Jota já havia dito, utilize as cláusulas
>>> LIMIT e OFFSET do SELECT.
>>> http://www.postgresql.org/docs/current/interactive/sql-select.html
>>>
>>> Para o seu exemplo:
>>> SELECT * FROM sua_tabela OFFSET 150 LIMIT 50 ORDER BY x;
>>>
>>> Para variar o OFFSET ou faça isso em sua aplicação ou crie uma função
>>> em que o valor do offset seja o parâmetro ou utilize um
>>> PREPARE/EXECUTE:
>>> http://www.postgresql.org/docs/current/interactive/sql-prepare.html
>>>
>>> Osvaldo
>>>  ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>
>>
>>
>> --
>> José de Mello Júnior
>> 41.9957-2007
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
>
> --
> Sérgio Antônio dos Santos
> Bacharel em Sistemas de Informação
> (31) 8573-7004
>
> ###
>
> Vem aí...
> SEARA 2009
> 21 a 24 de Fevereiro - Campus da UFV - Viçosa - MG
>
> "Alcancei misericórdia e a graça do Senhor foi imensa." (ITm 1, 13b, 14a)
>
> ___
> 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] Paginação

[Jota]

Olá,

Ótima dica do Guedes.



2009/2/18 Dickson S. Guedes :
> 2009/2/18 sergio santos :
>> Veja bem pessoal,
>> se eu usar o limit o método RecordCount do Adodb vai me retornar o valor
>> limit e não o número de registro.
>> Sendo assim, como estou fazendo uma paginação, vai ficar difícil saber o
>> número de páginas vou ter
>>
>> o que vocês acham?
>
> Ola Sergio,
>
> Você precisa saber *exatamente* quantas paginas darão? Uma estimativa
> (assim como o Google faz) já não ajudaria?
>
> Dependendo do tamanho desta sua tabela você pode aproveitar as
> estatísticas do banco, ao invés de fazer um count(*) para saber o
> total de registros e paginar.
>
> Faça um teste de exemplo em uma *base de teste*:
>
> CREATE TABLE temp (a int);
> INSERT INTO temp SELECT generate_series(1,10);
> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
> ANALYZE temp;
> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
> INSERT INTO temp SELECT generate_series(1,2);
> SELECT count(*) from temp;
> ANALYZE temp;
> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
> SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
> SELECT count(*) from temp;
> DROP TABLE temp;
>
> Veja como os resultados podem variar no caso do count a medida que o
> volume de dados vai crescendo.
>
> Obviamente o script acima não contem a solução pronta, é apenas uma
> demonstração de que é possível trabalhar com estimativas ao invés de
> exatos, em determinadas situações.
>
> Para se aprofundar, leia:
>
> http://www.postgresql.org/docs/current/static/monitoring-stats.html
>
>
> Dickson S. Guedes
> -
> mail/xmpp: gue...@guedesoft.net - skype: guediz
> http://guedesoft.net - http://planeta.postgresql.org.br
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
João Paulo
www.dextra.com.br/postgres
PostgreSQL
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[Dickson S. Guedes]

2009/2/18 sergio santos :
> Veja bem pessoal,
> se eu usar o limit o método RecordCount do Adodb vai me retornar o valor
> limit e não o número de registro.
> Sendo assim, como estou fazendo uma paginação, vai ficar difícil saber o
> número de páginas vou ter
>
> o que vocês acham?

Ola Sergio,

Você precisa saber *exatamente* quantas paginas darão? Uma estimativa
(assim como o Google faz) já não ajudaria?

Dependendo do tamanho desta sua tabela você pode aproveitar as
estatísticas do banco, ao invés de fazer um count(*) para saber o
total de registros e paginar.

Faça um teste de exemplo em uma *base de teste*:

CREATE TABLE temp (a int);
INSERT INTO temp SELECT generate_series(1,10);
SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
ANALYZE temp;
SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
INSERT INTO temp SELECT generate_series(1,2);
SELECT count(*) from temp;
ANALYZE temp;
SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
SELECT pg_stat_get_live_tuples(oid) from pg_class where relname = 'temp';
SELECT count(*) from temp;
DROP TABLE temp;

Veja como os resultados podem variar no caso do count a medida que o
volume de dados vai crescendo.

Obviamente o script acima não contem a solução pronta, é apenas uma
demonstração de que é possível trabalhar com estimativas ao invés de
exatos, em determinadas situações.

Para se aprofundar, leia:

http://www.postgresql.org/docs/current/static/monitoring-stats.html


Dickson S. Guedes
-
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://planeta.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] 1/2 off - sitema de arquivos linux

[Fernando França]

Telles se não me engano já escreveu um artigo sobre sistemas de arquivo, não?

Gostaria de sugerir também o ext4. Tenho utilizado ele muito bem - obrigado. =)

Pra quem estiver interessado, um briefing do ext4:

http://kernelnewbies.org/Ext4

Um tradução livre aqui do mesmo artigo:

http://andrem.wordpress.com/2008/12/26/ext4/

Achei uma opção a se considerar e pretendo testar em breve com o PostgreSQL.

--
Fernando França
Linux User #263682

CMAS/CBPDS *
DAN #2058378

http://desconstruindo.eng.br
http://www.cbpf.br/~lsd
http://www.rnp.br/keyserver/pks/lookup?search=0xB5E21164

Esta mensagem, incluindo seus anexos, contém informações legais
privilegiadas e/ou confidenciais, não podendo ser retransmitida,
arquivada,divulgada ou copiada sem autorização do remetente. Caso
tenha recebido esta mensagem por engano, por favor informe o remetente
respondendo imediatamente a este e-mail, e em seguida apague-a do seu
computador.

All information in this e-mail and attachments is confidential and
privileged. If you are not the intended addressee, please notify us
immediately by returning this e-mail and delete this message from your
computer. You should not forward, file, copy nor disclose this e-mail
to any other person without prior authorization.



2009/2/18 Eduardo :
> Fábio,
>
> Grato pelo comentário, ja ajudou e muito.!
>
>
> Eduardo
>
>
> Fábio Telles Rodriguez escreveu:
>> 2009/2/18 Eduardo :
>>
>>> Srs,
>>>
>>> Nas instalações atuais, qual sistema de arquivos os srs tem
>>> utilizado/Recomendado para uso com o banco?
>>>
>>> Ext3?
>>> RaserFS?
>>> Outro?
>>>
>>>
>>
>> Pergunta difícil...
>>
>> Ao invés de uma resposta clara, algumas considerações:
>>
>> 1) RaiserFS não é adequado para arquivos grandes como em bancos de dados.
>> 2) EXT3 é mais estável;
>> 3) XFS é um pouco mais rápido;
>> 4) Seja qual for o FS escolhido, se você fizer um tuning agressivo,
>> utilizando writeback, noauto, etc... a segurança pode diminuir em caso
>> de crash.
>> 5) Particionamento agressivo, uso de RAID, separação de tablespaces e
>> configurações de memória são EM GERAL mais importantes que uma longa
>> discussão sobre FS.
>> 6) Só mude o tamanho do bloco em casos muito expressivos como em
>> aplicações OLTP puras com MUITOS usuários ATIVOS simultâneos,,(quando
>> diminuir o tamanho do bloco pode ajudar um pouco) ou em aplicações de
>> suporte a decisão com a maioria dos objetos ENORMES (imagine aqui
>> índices com mais de 10GB como algo normal) onde aumentar o tamanho do
>> bloco pode ajudar.
>> 7) Uma configuração mais específica de FS em geral consegue melhorar
>> 5% a 10% em algumas operações do banco e piorar de 30% a 60% em
>> outras. Pense bem antes de se aventurar nisso.
>>
>> Em geral a minha resposta é: fique entre o EXT3 e o XFS e se preocupe
>> com outras coisas mais importantes. É claro que você pode fazer uma
>> combinação mais exótica como: ext2 nos tablespaces, XFS para o WAL e
>> EXT3 para o resto... mas isso é muita viagem e para provar que isso ou
>> outra configuração é melhor ou pior iria levar meses de testes por
>> equipe muito bem qualificada...
>>
>> Acho que é isso, a experiência de alguém aqui na lista aponta para
>> outra direção?
>>
>> []s
>> Fábio Telles
>>
>
>
> --
>
> Eduardo Nakamatu
> Consultor de Negócios, Instrutor ADVPL Senior
> Certificado Microsiga
> Biale ADVPL Consultoria e Treinamentos.
> FoneFax: (11) 5011-4895
> e-mail: eduardo(at)advpl(dot)com(dot)br
> www.biale.com.br
> www.advpl.com.br
>
> ___
> 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] Paginação

[sergio santos]

Veja bem pessoal,
se eu usar o limit o método RecordCount do Adodb vai me retornar o valor
limit e não o número de registro.
Sendo assim, como estou fazendo uma paginação, vai ficar difícil saber o
número de páginas vou ter

o que vocês acham?

2009/2/18 José Mello Júnior 

> Endendo que a questão está muito mais para a ótica de um aplicativo do que
> para o SGBD, mas aproveitando esta dúvida eu gostaria de perguntar o
> seguinte: em um caso como esse, é mais fácil (ou dinâmico) a manipulação de
> um cursor, onde o postgres se preocupa com o dimensionamento do resultado ou
> utilizando LIMIT e OFFSET as consultas são de alguma forma otimizadas?
>
> []´s
>
> 2009/2/18 Osvaldo Kussama 
>
>> 2009/2/18 sergio santos :
>> >
>> > tô me referindo a paginação em SQL
>> > exemplo: se minha consulta retornar 1000 registros tenho que passar um
>> > parâmetro para o banco informando que quero exibir somente os registros
>> > entre 150 e 200 ou seja, serão exibidos 50 registro, isso de forma
>> dinâmica
>> > fazendo com que a minha consulta sql faça uma paginação.
>> >
>>
>>
>> Então, reafirmando o que Jota já havia dito, utilize as cláusulas
>> LIMIT e OFFSET do SELECT.
>> http://www.postgresql.org/docs/current/interactive/sql-select.html
>>
>> Para o seu exemplo:
>> SELECT * FROM sua_tabela OFFSET 150 LIMIT 50 ORDER BY x;
>>
>> Para variar o OFFSET ou faça isso em sua aplicação ou crie uma função
>> em que o valor do offset seja o parâmetro ou utilize um
>> PREPARE/EXECUTE:
>> http://www.postgresql.org/docs/current/interactive/sql-prepare.html
>>
>> Osvaldo
>>  ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> José de Mello Júnior
> 41.9957-2007
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>


-- 
Sérgio Antônio dos Santos
Bacharel em Sistemas de Informação
(31) 8573-7004

###

Vem aí...
SEARA 2009
21 a 24 de Fevereiro - Campus da UFV - Viçosa - MG

"Alcancei misericórdia e a graça do Senhor foi imensa." (ITm 1, 13b, 14a)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Busca de gargalo.

[André Ormenese ( Yahoo )]

Luigi Castro Cardeles escreveu:
> Olá,
>
> tem uma versão do kernel que permite usar mais de 3G de RAM em uma 
> máquina 32 bits.
> Não sei o limite (testei em uma máquina com 4G de ram) mas acho que é 
> o kernel PAE (se você procurar por pacotes).
>
> []'s
>
> 2009/2/18 "André Ormenese ( Yahoo )"  >
>
> Sebastian SWC escreveu:
> > 2009/2/18 "André Ormenese ( Yahoo )"  >:
> > 
> >
> >> Hardware :
> >> HP Proliant 380 G5, com dois processadores Intel Xeon Quad core
> de 1.86 GHz;
> >> 16 GB ram
> >> 4 discos SCSI de 72 GB com 10k rpm, em RAID 1+0 gerenciado pela
> >> controladora P 400 smart array.
> >>
> >
> > semana passada montei um 350 g5, são ótimos esses servers!
> >
> >
> >> SO.:
> >> FreeBSD 6.2 Release #1 para 32 bits em função do processador
> Intel Xeon.
> >>
> >
> > os processadores xeon suportam 64 bits, qual é o modelo dos seus
> processadores?
> >
> >
> >> Mas o SO só enxerga 3 GB de ram !!!
> >>
> >
> > no linux é um problema comum por usar ambiente 32 bits... eu uso
> > amd64, mas pra x86 me parece q tem um patch do kernel pra resolver
> > isso. no bsd é a mesma coisa? não sei dizer.
> >
> >
> Processador : Intel(R) Xeon(R) CPUE5320  @ 1.86GHz
> Já confirmei e o processador tem suporte a 64 bits. Vou detonar a
> máquina e começar do zero. Só que isso vai demorar um pouco. Entro de
> férias sexta  ( Uuuuffaaa!!!)
> Assim que montar a máquina e banco, vou fazer a carga de dados
> novamente, e aí mando notícias.
>
> Mas se alguém aí tiver umas dicas para parametrizar o
> postgresql.conf em
> função da qtdade de memória, eu agradeço.
>
> Valeu pela ajuda galera.
> Até
> André
>
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> 
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
>
>
> -- 
> Luigi Castro Cardeles
> 
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>   
Esta opção já está ativada no kernel, mas mesmo assim não funcionou. Veja :

CPU: Intel(R) Xeon(R) CPU   E5320  @ 1.86GHz (1866.68-MHz 
686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6f7  Stepping = 7
  
Features=0xbfebfbff

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Carga noturna, TXT ou XML?

[Osvaldo Kussama]

2009/2/18 Guilherme Carvalho :
> Mas no caso o DBLINK acessaria um outro SGBD, no caso eu teria como fazer o
> postgreSQL com o DBLINK acessar uma base em Firebird? Pelo que li neste
> wiki,
> http://pt.wikibooks.org/wiki/PostgreSQL_Pr%C3%A1tico/Replica%C3%A7%C3%A3o,
> o DBLINK é para replicação entre bases PostgreSQL.
>


Faltou um "i".
Veja DBI-Link:
http://pgfoundry.org/projects/dbi-link

Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] 1/2 off - sitema de arquivos linux

[Eduardo]

Fábio,

Grato pelo comentário, ja ajudou e muito.!


Eduardo


Fábio Telles Rodriguez escreveu:
> 2009/2/18 Eduardo :
>   
>> Srs,
>>
>> Nas instalações atuais, qual sistema de arquivos os srs tem
>> utilizado/Recomendado para uso com o banco?
>>
>> Ext3?
>> RaserFS?
>> Outro?
>>
>> 
>
> Pergunta difícil...
>
> Ao invés de uma resposta clara, algumas considerações:
>
> 1) RaiserFS não é adequado para arquivos grandes como em bancos de dados.
> 2) EXT3 é mais estável;
> 3) XFS é um pouco mais rápido;
> 4) Seja qual for o FS escolhido, se você fizer um tuning agressivo,
> utilizando writeback, noauto, etc... a segurança pode diminuir em caso
> de crash.
> 5) Particionamento agressivo, uso de RAID, separação de tablespaces e
> configurações de memória são EM GERAL mais importantes que uma longa
> discussão sobre FS.
> 6) Só mude o tamanho do bloco em casos muito expressivos como em
> aplicações OLTP puras com MUITOS usuários ATIVOS simultâneos,,(quando
> diminuir o tamanho do bloco pode ajudar um pouco) ou em aplicações de
> suporte a decisão com a maioria dos objetos ENORMES (imagine aqui
> índices com mais de 10GB como algo normal) onde aumentar o tamanho do
> bloco pode ajudar.
> 7) Uma configuração mais específica de FS em geral consegue melhorar
> 5% a 10% em algumas operações do banco e piorar de 30% a 60% em
> outras. Pense bem antes de se aventurar nisso.
>
> Em geral a minha resposta é: fique entre o EXT3 e o XFS e se preocupe
> com outras coisas mais importantes. É claro que você pode fazer uma
> combinação mais exótica como: ext2 nos tablespaces, XFS para o WAL e
> EXT3 para o resto... mas isso é muita viagem e para provar que isso ou
> outra configuração é melhor ou pior iria levar meses de testes por
> equipe muito bem qualificada...
>
> Acho que é isso, a experiência de alguém aqui na lista aponta para
> outra direção?
>
> []s
> Fábio Telles
>   


-- 

Eduardo Nakamatu
Consultor de Negócios, Instrutor ADVPL Senior
Certificado Microsiga
Biale ADVPL Consultoria e Treinamentos.
FoneFax: (11) 5011-4895
e-mail: eduardo(at)advpl(dot)com(dot)br 
www.biale.com.br
www.advpl.com.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] 1/2 off - sitema de arquivos linux

[Eduardo]

Jota,

Estou levantando essa questão, pois não trabalho muito com "infra", 
Administro sistemas de gestão, e recentemente tive problemas com um 
servidor SuSe que sofreu a famosa queda de força, configurado com 
RaiserFS, depois de 5 horas conseguimos levantar o servidor e agora 
parece que esta estável.

Estou apenas preocupado, pois sempre ouvi falar que o RaiserFS não é o 
mais indicado em instalações onde oscilações de força são recorrentes, 
por isso miha duvida...

Vou estudar o XFS, mais alguma indicação?

Eduardo



Jota escreveu:
> Olá,
>
> É uma boa pergunta. Apenas uma correção é ReiserFS e não RaserFS. Tem
> o XFS também que é bastante rápido.
>
> Depende muito do que você necessita. Por exemplo, o EXT3 não suporte
> redimensionamento para blocos superiores a 8k e a restauração do
> journaling é lento.
>
> Abraços
>
>
> 2009/2/18 Eduardo :
>   
>> Srs,
>>
>> Nas instalações atuais, qual sistema de arquivos os srs tem
>> utilizado/Recomendado para uso com o banco?
>>
>> Ext3?
>> RaserFS?
>> Outro?
>>
>> --
>>
>> Eduardo
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>> 
>
>
>
>   


-- 

Eduardo Nakamatu
Consultor de Negócios, Instrutor ADVPL Senior
Certificado Microsiga
Biale ADVPL Consultoria e Treinamentos.
FoneFax: (11) 5011-4895
e-mail: eduardo(at)advpl(dot)com(dot)br 
www.biale.com.br
www.advpl.com.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] 1/2 off - sitema de arquivos linux

[Fábio Telles Rodriguez]

2009/2/18 Eduardo :
> Srs,
>
> Nas instalações atuais, qual sistema de arquivos os srs tem
> utilizado/Recomendado para uso com o banco?
>
> Ext3?
> RaserFS?
> Outro?
>

Pergunta difícil...

Ao invés de uma resposta clara, algumas considerações:

1) RaiserFS não é adequado para arquivos grandes como em bancos de dados.
2) EXT3 é mais estável;
3) XFS é um pouco mais rápido;
4) Seja qual for o FS escolhido, se você fizer um tuning agressivo,
utilizando writeback, noauto, etc... a segurança pode diminuir em caso
de crash.
5) Particionamento agressivo, uso de RAID, separação de tablespaces e
configurações de memória são EM GERAL mais importantes que uma longa
discussão sobre FS.
6) Só mude o tamanho do bloco em casos muito expressivos como em
aplicações OLTP puras com MUITOS usuários ATIVOS simultâneos,,(quando
diminuir o tamanho do bloco pode ajudar um pouco) ou em aplicações de
suporte a decisão com a maioria dos objetos ENORMES (imagine aqui
índices com mais de 10GB como algo normal) onde aumentar o tamanho do
bloco pode ajudar.
7) Uma configuração mais específica de FS em geral consegue melhorar
5% a 10% em algumas operações do banco e piorar de 30% a 60% em
outras. Pense bem antes de se aventurar nisso.

Em geral a minha resposta é: fique entre o EXT3 e o XFS e se preocupe
com outras coisas mais importantes. É claro que você pode fazer uma
combinação mais exótica como: ext2 nos tablespaces, XFS para o WAL e
EXT3 para o resto... mas isso é muita viagem e para provar que isso ou
outra configuração é melhor ou pior iria levar meses de testes por
equipe muito bem qualificada...

Acho que é isso, a experiência de alguém aqui na lista aponta para
outra direção?

[]s
Fábio Telles
-- 
blog: http://www.midstorm.org/~telles/
e-mail / jabber: fabio.tel...@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] Carga noturna, TXT ou XML?

[Jota]

Olá,

O dblink é a grosso modo uma forma de você se conectar a outro SGBD e
manipular os dados dos SGBDs envolvidos.

[]s

2009/2/18 Guilherme Carvalho :
> Mas no caso o DBLINK acessaria um outro SGBD, no caso eu teria como fazer o
> postgreSQL com o DBLINK acessar uma base em Firebird? Pelo que li neste
> wiki,
> http://pt.wikibooks.org/wiki/PostgreSQL_Pr%C3%A1tico/Replica%C3%A7%C3%A3o,
> o DBLINK é para replicação entre bases PostgreSQL.
>
> 2009/2/18 José Mello Júnior 
>>
>> Através de um comando INSERT annhado com um select do DBLINK vc obtém as
>> informações e a atualização. Já fiz isto no access para um sistema da
>> Receita Federal e funcionou muito bem.
>>
>> []´s
>>
>> 2009/2/18 
>>>
>>> Uma boa opção é acessar diretamente os dados do firebird usando pljava
>>> com um drive jdbc adequado
>>>
>>> 2009/2/17 Guilherme Carvalho 

 Estou com uma demanda para ler dados de um outro banco, Firebird, todas
 as noites e trazer para um banco PostgreSQL, neste caso o melhor é ler de 
 um
 arquivo txt ou de um arquivo XML?


 Atenciosamente
 Guilherme de Carvalho Carneiro.

 ___
 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
>>>
>>
>>
>>
>> --
>> José de Mello Júnior
>> 41.9957-2007
>>
>> ___
>> 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
>
>



-- 
João Paulo
www.dextra.com.br/postgres
PostgreSQL
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] 1/2 off - sitema de arquivos linux

[Jota]

Olá,

É uma boa pergunta. Apenas uma correção é ReiserFS e não RaserFS. Tem
o XFS também que é bastante rápido.

Depende muito do que você necessita. Por exemplo, o EXT3 não suporte
redimensionamento para blocos superiores a 8k e a restauração do
journaling é lento.

Abraços


2009/2/18 Eduardo :
> Srs,
>
> Nas instalações atuais, qual sistema de arquivos os srs tem
> utilizado/Recomendado para uso com o banco?
>
> Ext3?
> RaserFS?
> Outro?
>
> --
>
> Eduardo
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
João Paulo
www.dextra.com.br/postgres
PostgreSQL
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[Jota]

Olá,

Bem lembrado pelo Osvaldo, se você utilizar um cursor deve manter uma
transação em aberto para processar.

Também não sei precisar qual é mais eficiente.

[]s

2009/2/18 Osvaldo Kussama :
> 2009/2/18 José Mello Júnior :
>> Endendo que a questão está muito mais para a ótica de um aplicativo do que
>> para o SGBD, mas aproveitando esta dúvida eu gostaria de perguntar o
>> seguinte: em um caso como esse, é mais fácil (ou dinâmico) a manipulação de
>> um cursor, onde o postgres se preocupa com o dimensionamento do resultado ou
>> utilizando LIMIT e OFFSET as consultas são de alguma forma otimizadas?
>>
>
>
> Creio que para utilizar CURSOR neste caso você necessita manter uma
> transação aberta.
>
> Se isso não for um empecilho é realmente uma alternativa.
>
> Não sei qual das soluções (CURSOR ou OFFSET/LIMIT) é mais eficiente.
>
> Osvaldo
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
João Paulo
www.dextra.com.br/postgres
PostgreSQL
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PGNP - OLEDB - ODBC

[freebsd.br]

-- Cabeçalho original ---

De: pgbr-geral-boun...@listas.postgresql.org.br
Para: "Comunidade PostgreSQL Brasileira" pgbr-geral@listas.postgresql.org.br
Cópia: 
Data: Wed, 18 Feb 2009 10:28:25 -0300
Assunto: Re: [pgbr-geral] PGNP - OLEDB - ODBC

> 2009/2/17 Robison Geraldi Garcia :
> > Boa noite;
> 
> Bom dia!
> 
> 
> > Olá pessoal como vão tudo bem?
> >
> > Gostaria de deixar uma dúvida em relação há drivers para o Windows.
> >
> > Sei que é uma merda Windows, mais fazer o que.
> >
> 
> Simplesmente não use.  =)
> 
> >
> > A dúvida é a seguinte:
> >
> >
> >
> > Foi comprada uma solução XYZ, que fará consultas em meu banco de dados.
> >
> > Esta solução está rodando em cima do Sistema Operacional Windows 2003 Server
> > 64 bit.
> >
> > Não estou conseguindo fazer uma conexão ODBC, OLEDB com minha base de dados,
> > antes que qualquer pergunte em relação a configurações no postgres, posso
> > afirmar que está tudo correto pois outras máquinas rodam normalmente, o
> > problema é a merda do Windows 2003 server 64.
> >
> 
> Qual é o erro? vc tentou gerar um log de odbc? como ficou sua
> configuração no pg_hba?
> 
> -- 
> Atenciosamente,
> Sebastian Selau Webber Colombo
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



Boa tarde;


Caro Sebastian obrigado por me responder, mais acho que você não leu meu email 
inteiro.
Mesmo assim irei responder suas perguntas.

O odbc esta configurado corretamente, foi configurado para liberar a minha rede 
toda pedindo senha ou seja: 
host  all all minha_rede_blbablabla MD5 
Em questão ao ODBC ele não roda em cima do Windows 2003 server 64 bits, esse é 
o meu problema.
Tentei com OleDB mais tb nao roda na plataforma 64bits;


O problema não é permissão de acesso ao qualquer coisa com o banco de dados e 
sim com o conector para acesso;

Muito obrigado.

Robison Geraldi Garcia


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Busca de gargalo.

[Luigi Castro Cardeles]

Olá,

tem uma versão do kernel que permite usar mais de 3G de RAM em uma máquina
32 bits.
Não sei o limite (testei em uma máquina com 4G de ram) mas acho que é o
kernel PAE (se você procurar por pacotes).

[]'s

2009/2/18 "André Ormenese ( Yahoo )" 

> Sebastian SWC escreveu:
> > 2009/2/18 "André Ormenese ( Yahoo )" :
> > 
> >
> >> Hardware :
> >> HP Proliant 380 G5, com dois processadores Intel Xeon Quad core de 1.86
> GHz;
> >> 16 GB ram
> >> 4 discos SCSI de 72 GB com 10k rpm, em RAID 1+0 gerenciado pela
> >> controladora P 400 smart array.
> >>
> >
> > semana passada montei um 350 g5, são ótimos esses servers!
> >
> >
> >> SO.:
> >> FreeBSD 6.2 Release #1 para 32 bits em função do processador Intel Xeon.
> >>
> >
> > os processadores xeon suportam 64 bits, qual é o modelo dos seus
> processadores?
> >
> >
> >> Mas o SO só enxerga 3 GB de ram !!!
> >>
> >
> > no linux é um problema comum por usar ambiente 32 bits... eu uso
> > amd64, mas pra x86 me parece q tem um patch do kernel pra resolver
> > isso. no bsd é a mesma coisa? não sei dizer.
> >
> >
> Processador : Intel(R) Xeon(R) CPUE5320  @ 1.86GHz
> Já confirmei e o processador tem suporte a 64 bits. Vou detonar a
> máquina e começar do zero. Só que isso vai demorar um pouco. Entro de
> férias sexta  ( Uuuuffaaa!!!)
> Assim que montar a máquina e banco, vou fazer a carga de dados
> novamente, e aí mando notícias.
>
> Mas se alguém aí tiver umas dicas para parametrizar o postgresql.conf em
> função da qtdade de memória, eu agradeço.
>
> Valeu pela ajuda galera.
> Até
> André
>
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Luigi Castro Cardeles
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Carga noturna, TXT ou XML?

[Guilherme Carvalho]

Mas no caso o DBLINK acessaria um outro SGBD, no caso eu teria como fazer o
postgreSQL com o DBLINK acessar uma base em Firebird? Pelo que li neste
wiki,
http://pt.wikibooks.org/wiki/PostgreSQL_Pr%C3%A1tico/Replica%C3%A7%C3%A3o,
o DBLINK é para replicação entre bases PostgreSQL.

2009/2/18 José Mello Júnior 

> Através de um comando INSERT annhado com um select do DBLINK vc obtém as
> informações e a atualização. Já fiz isto no access para um sistema da
> Receita Federal e funcionou muito bem.
>
> []´s
>
> 2009/2/18 
>
> Uma boa opção é acessar diretamente os dados do firebird usando pljava com
>> um drive jdbc adequado
>>
>>  2009/2/17 Guilherme Carvalho 
>>
>>> Estou com uma demanda para ler dados de um outro banco, Firebird, todas
>>> as noites e trazer para um banco PostgreSQL, neste caso o melhor é ler de um
>>> arquivo txt ou de um arquivo XML?
>>>
>>>
>>> Atenciosamente
>>> Guilherme de Carvalho Carneiro.
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> José de Mello Júnior
> 41.9957-2007
>
> ___
> 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] 1/2 off - sitema de arquivos linux

[Eduardo]

Srs,

Nas instalações atuais, qual sistema de arquivos os srs tem 
utilizado/Recomendado para uso com o banco?

Ext3?
RaserFS?
Outro?

-- 

Eduardo 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[Osvaldo Kussama]

2009/2/18 José Mello Júnior :
> Endendo que a questão está muito mais para a ótica de um aplicativo do que
> para o SGBD, mas aproveitando esta dúvida eu gostaria de perguntar o
> seguinte: em um caso como esse, é mais fácil (ou dinâmico) a manipulação de
> um cursor, onde o postgres se preocupa com o dimensionamento do resultado ou
> utilizando LIMIT e OFFSET as consultas são de alguma forma otimizadas?
>


Creio que para utilizar CURSOR neste caso você necessita manter uma
transação aberta.

Se isso não for um empecilho é realmente uma alternativa.

Não sei qual das soluções (CURSOR ou OFFSET/LIMIT) é mais eficiente.

Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Busca de gargalo.

[André Ormenese ( Yahoo )]

Sebastian SWC escreveu:
> 2009/2/18 "André Ormenese ( Yahoo )" :
> 
>   
>> Hardware :
>> HP Proliant 380 G5, com dois processadores Intel Xeon Quad core de 1.86 GHz;
>> 16 GB ram
>> 4 discos SCSI de 72 GB com 10k rpm, em RAID 1+0 gerenciado pela
>> controladora P 400 smart array.
>> 
>
> semana passada montei um 350 g5, são ótimos esses servers!
>
>   
>> SO.:
>> FreeBSD 6.2 Release #1 para 32 bits em função do processador Intel Xeon.
>> 
>
> os processadores xeon suportam 64 bits, qual é o modelo dos seus 
> processadores?
>
>   
>> Mas o SO só enxerga 3 GB de ram !!!
>> 
>
> no linux é um problema comum por usar ambiente 32 bits... eu uso
> amd64, mas pra x86 me parece q tem um patch do kernel pra resolver
> isso. no bsd é a mesma coisa? não sei dizer.
>
>   
Processador : Intel(R) Xeon(R) CPUE5320  @ 1.86GHz
Já confirmei e o processador tem suporte a 64 bits. Vou detonar a 
máquina e começar do zero. Só que isso vai demorar um pouco. Entro de 
férias sexta  ( Uuuuffaaa!!!)
Assim que montar a máquina e banco, vou fazer a carga de dados 
novamente, e aí mando notícias.

Mas se alguém aí tiver umas dicas para parametrizar o postgresql.conf em 
função da qtdade de memória, eu agradeço.

Valeu pela ajuda galera.
Até
André




___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[José Mello Júnior]

Endendo que a questão está muito mais para a ótica de um aplicativo do que
para o SGBD, mas aproveitando esta dúvida eu gostaria de perguntar o
seguinte: em um caso como esse, é mais fácil (ou dinâmico) a manipulação de
um cursor, onde o postgres se preocupa com o dimensionamento do resultado ou
utilizando LIMIT e OFFSET as consultas são de alguma forma otimizadas?

[]´s

2009/2/18 Osvaldo Kussama 

> 2009/2/18 sergio santos :
> >
> > tô me referindo a paginação em SQL
> > exemplo: se minha consulta retornar 1000 registros tenho que passar um
> > parâmetro para o banco informando que quero exibir somente os registros
> > entre 150 e 200 ou seja, serão exibidos 50 registro, isso de forma
> dinâmica
> > fazendo com que a minha consulta sql faça uma paginação.
> >
>
>
> Então, reafirmando o que Jota já havia dito, utilize as cláusulas
> LIMIT e OFFSET do SELECT.
> http://www.postgresql.org/docs/current/interactive/sql-select.html
>
> Para o seu exemplo:
> SELECT * FROM sua_tabela OFFSET 150 LIMIT 50 ORDER BY x;
>
> Para variar o OFFSET ou faça isso em sua aplicação ou crie uma função
> em que o valor do offset seja o parâmetro ou utilize um
> PREPARE/EXECUTE:
> http://www.postgresql.org/docs/current/interactive/sql-prepare.html
>
> Osvaldo
>  ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
José de Mello Júnior
41.9957-2007
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[sergio santos]

ok Osvaldo
certinho!

obrigado pela atenção

abraços



2009/2/18 Osvaldo Kussama 

> 2009/2/18 sergio santos :
> >
> > tô me referindo a paginação em SQL
> > exemplo: se minha consulta retornar 1000 registros tenho que passar um
> > parâmetro para o banco informando que quero exibir somente os registros
> > entre 150 e 200 ou seja, serão exibidos 50 registro, isso de forma
> dinâmica
> > fazendo com que a minha consulta sql faça uma paginação.
> >
>
>
> Então, reafirmando o que Jota já havia dito, utilize as cláusulas
> LIMIT e OFFSET do SELECT.
> http://www.postgresql.org/docs/current/interactive/sql-select.html
>
> Para o seu exemplo:
> SELECT * FROM sua_tabela OFFSET 150 LIMIT 50 ORDER BY x;
>
> Para variar o OFFSET ou faça isso em sua aplicação ou crie uma função
> em que o valor do offset seja o parâmetro ou utilize um
> PREPARE/EXECUTE:
> http://www.postgresql.org/docs/current/interactive/sql-prepare.html
>
> Osvaldo
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Sérgio Antônio dos Santos
Bacharel em Sistemas de Informação
(31) 8573-7004

###

Vem aí...
SEARA 2009
21 a 24 de Fevereiro - Campus da UFV - Viçosa - MG

"Alcancei misericórdia e a graça do Senhor foi imensa." (ITm 1, 13b, 14a)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Carga noturna, TXT ou XML?

[José Mello Júnior]

Através de um comando INSERT annhado com um select do DBLINK vc obtém as
informações e a atualização. Já fiz isto no access para um sistema da
Receita Federal e funcionou muito bem.

[]´s

2009/2/18 

> Uma boa opção é acessar diretamente os dados do firebird usando pljava com
> um drive jdbc adequado
>
>  2009/2/17 Guilherme Carvalho 
>
>> Estou com uma demanda para ler dados de um outro banco, Firebird, todas as
>> noites e trazer para um banco PostgreSQL, neste caso o melhor é ler de um
>> arquivo txt ou de um arquivo XML?
>>
>>
>> Atenciosamente
>> Guilherme de Carvalho Carneiro.
>>
>> ___
>> 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
>
>


-- 
José de Mello Júnior
41.9957-2007
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[Osvaldo Kussama]

2009/2/18 sergio santos :
>
> tô me referindo a paginação em SQL
> exemplo: se minha consulta retornar 1000 registros tenho que passar um
> parâmetro para o banco informando que quero exibir somente os registros
> entre 150 e 200 ou seja, serão exibidos 50 registro, isso de forma dinâmica
> fazendo com que a minha consulta sql faça uma paginação.
>


Então, reafirmando o que Jota já havia dito, utilize as cláusulas
LIMIT e OFFSET do SELECT.
http://www.postgresql.org/docs/current/interactive/sql-select.html

Para o seu exemplo:
SELECT * FROM sua_tabela OFFSET 150 LIMIT 50 ORDER BY x;

Para variar o OFFSET ou faça isso em sua aplicação ou crie uma função
em que o valor do offset seja o parâmetro ou utilize um
PREPARE/EXECUTE:
http://www.postgresql.org/docs/current/interactive/sql-prepare.html

Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[Dickson S. Guedes]

2009/2/18 sergio santos :
> Olá Jota,
> obrigado pela resposta
>
> tô me referindo a paginação em SQL
> exemplo: se minha consulta retornar 1000 registros tenho que passar um
> parâmetro para o banco informando que quero exibir somente os registros
> entre 150 e 200 ou seja, serão exibidos 50 registro, isso de forma dinâmica
> fazendo com que a minha consulta sql faça uma paginação.

Dê uma olhada aqui e veja se te ajuda.

http://www.postgresql.org/docs/current/static/queries-limit.html

Dickson S. Guedes
-
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://planeta.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] PGNP - OLEDB - ODBC

[Sebastian SWC]

2009/2/17 Robison Geraldi Garcia :
> Boa noite;

Bom dia!


> Olá pessoal como vão tudo bem?
>
> Gostaria de deixar uma dúvida em relação há drivers para o Windows.
>
> Sei que é uma merda Windows, mais fazer o que.
>

Simplesmente não use.  =)

>
> A dúvida é a seguinte:
>
>
>
> Foi comprada uma solução XYZ, que fará consultas em meu banco de dados.
>
> Esta solução está rodando em cima do Sistema Operacional Windows 2003 Server
> 64 bit.
>
> Não estou conseguindo fazer uma conexão ODBC, OLEDB com minha base de dados,
> antes que qualquer pergunte em relação a configurações no postgres, posso
> afirmar que está tudo correto pois outras máquinas rodam normalmente, o
> problema é a merda do Windows 2003 server 64.
>

Qual é o erro? vc tentou gerar um log de odbc? como ficou sua
configuração no pg_hba?

-- 
Atenciosamente,
Sebastian Selau Webber Colombo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[sergio santos]

Olá Jota,
obrigado pela resposta

tô me referindo a paginação em SQL
exemplo: se minha consulta retornar 1000 registros tenho que passar um
parâmetro para o banco informando que quero exibir somente os registros
entre 150 e 200 ou seja, serão exibidos 50 registro, isso de forma dinâmica
fazendo com que a minha consulta sql faça uma paginação.

acho que é isso.


2009/2/18 Jota 

> Olá,
>
> Qual tipo de paginação você está se referindo? A paginação interna ou
> você fala paginação através do limit e offset (select campo1,campo2
> from tabela limit 10) para a exibição dos registros?
>
> []s
>
> 2009/2/18 sergio santos :
> > Pessoal,
> > tô estudando sobre paginação no PostgreSQL.
> >
> > dei uma olhadinha na lista e achei algumas coisas interessantes. No
> entanto,
> > estou enviando este email para ver se alguém tem algum link que me mostre
> > bem detalhado como é o processo de paginação no PostgreSQL.
> >
> > Exemplo
> > Se eu tenho um SQL que vai me retornar 1 registros quero exibir 50
> por
> > páginas.
> >
> > obrigado pela atenção
> >
> > --
> > Sérgio Antônio dos Santos
> > Bacharel em Sistemas de Informação
> > (31) 8573-7004
> >
> > ###
> >
> > Vem aí...
> > SEARA 2009
> > 21 a 24 de Fevereiro - Campus da UFV - Viçosa - MG
> >
> > "Alcancei misericórdia e a graça do Senhor foi imensa." (ITm 1, 13b, 14a)
> >
> > ___
> > pgbr-geral mailing list
> > pgbr-geral@listas.postgresql.org.br
> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >
> >
>
>
>
> --
> João Paulo
> www.dextra.com.br/postgres
> PostgreSQL
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Sérgio Antônio dos Santos
Bacharel em Sistemas de Informação
(31) 8573-7004

###

Vem aí...
SEARA 2009
21 a 24 de Fevereiro - Campus da UFV - Viçosa - MG

"Alcancei misericórdia e a graça do Senhor foi imensa." (ITm 1, 13b, 14a)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Busca de gargalo.

[Sebastian SWC]

2009/2/18 "André Ormenese ( Yahoo )" :

> Hardware :
> HP Proliant 380 G5, com dois processadores Intel Xeon Quad core de 1.86 GHz;
> 16 GB ram
> 4 discos SCSI de 72 GB com 10k rpm, em RAID 1+0 gerenciado pela
> controladora P 400 smart array.

semana passada montei um 350 g5, são ótimos esses servers!

> SO.:
> FreeBSD 6.2 Release #1 para 32 bits em função do processador Intel Xeon.

os processadores xeon suportam 64 bits, qual é o modelo dos seus processadores?

> Mas o SO só enxerga 3 GB de ram !!!

no linux é um problema comum por usar ambiente 32 bits... eu uso
amd64, mas pra x86 me parece q tem um patch do kernel pra resolver
isso. no bsd é a mesma coisa? não sei dizer.

-- 
Atenciosamente,
Sebastian Selau Webber Colombo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Busca de gargalo.

[Benedito A. Cruz]

André Ormenese ( Yahoo ) wrote:


Mas o SO só enxerga 3 GB de ram !!!

  
Isso é por causa da arquitetura i386, que só enxerga 4GB de RAM (e a MB 
deve estar usando 1GB internamente).

Acho que você deveria começar instalando o kernel amd64.

[]s

 Bene




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

begin:vcard
fn:Benedito A  Cruz
n:Cruz;Benedito A 
email;internet:b...@cria.org.br
title:Prof.
tel;work:+55 19 3288 0466
tel;home:+55 19 3406 5775
tel;cell:+55 19 8122 6110
x-mozilla-html:TRUE
version:2.1
end:vcard

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Busca de gargalo.

[André Ormenese ( Yahoo )]

Sebastian SWC escreveu:
> On Tue, Feb 17, 2009 at 3:46 PM, "André Ormenese ( Yahoo )"
>  wrote:
>   
>> Boa tarde pessoal !!
>> Estou montando um servidor de banco com FreeBSD 6.2 e PostgreSQL 8.3.6.
>> Neste momento estou fazendo uma carga de dados, mas estou achando muito
>> lento.
>> Como saber se o problema está na configuração do postgresql.conf, ou se
>> é problema de I/O ???
>>
>> 
>
> q tal começar a detalhar mais o seu ambiente?
>
>   
Então vamos lá !!
Estou respondendo a algumas perguntas que o pessoal fez !!!



Hardware :
HP Proliant 380 G5, com dois processadores Intel Xeon Quad core de 1.86 GHz;
16 GB ram
4 discos SCSI de 72 GB com 10k rpm, em RAID 1+0 gerenciado pela 
controladora P 400 smart array.

SO.:
FreeBSD 6.2 Release #1 para 32 bits em função do processador Intel Xeon.
Mas o SO só enxerga 3 GB de ram !!!

Banco:
Postgresql 8.3.6
As únicas configurações que habilitei foram :

max_connections = 100
#--
# RESOURCE USAGE (except WAL)
#--

# - Memory -

shared_buffers = 20MB 
#temp_buffers = 8MB  
#max_prepared_transactions = 5
  
# Note:  Increasing max_prepared_transactions costs ~600 bytes of shared 
memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
work_mem = 1MB 
maintenance_work_mem = 5MB 
max_stack_depth = 1MB 

# - Free Space Map -

max_fsm_pages = 204800

#max_fsm_relations = 1000  
  
Como eu disse no email anterior, não tenho uma regra/fórmula para a 
definição destes parâmetros.

Só mais uma coisa, qdo fiz a carga de dados, através do psql, verifiquei 
no top, do freebsd, que o parâmetro WCPU ficou bem baixo, em torno de 0,30 %

Obrigado pela força.
André

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paginação

[Jota]

Olá,

Qual tipo de paginação você está se referindo? A paginação interna ou
você fala paginação através do limit e offset (select campo1,campo2
from tabela limit 10) para a exibição dos registros?

[]s

2009/2/18 sergio santos :
> Pessoal,
> tô estudando sobre paginação no PostgreSQL.
>
> dei uma olhadinha na lista e achei algumas coisas interessantes. No entanto,
> estou enviando este email para ver se alguém tem algum link que me mostre
> bem detalhado como é o processo de paginação no PostgreSQL.
>
> Exemplo
> Se eu tenho um SQL que vai me retornar 1 registros quero exibir 50 por
> páginas.
>
> obrigado pela atenção
>
> --
> Sérgio Antônio dos Santos
> Bacharel em Sistemas de Informação
> (31) 8573-7004
>
> ###
>
> Vem aí...
> SEARA 2009
> 21 a 24 de Fevereiro - Campus da UFV - Viçosa - MG
>
> "Alcancei misericórdia e a graça do Senhor foi imensa." (ITm 1, 13b, 14a)
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>



-- 
João Paulo
www.dextra.com.br/postgres
PostgreSQL
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Paginação

[sergio santos]

Pessoal,
tô estudando sobre paginação no PostgreSQL.

dei uma olhadinha na lista e achei algumas coisas interessantes. No entanto,
estou enviando este email para ver se alguém tem algum link que me mostre
bem detalhado como é o processo de paginação no PostgreSQL.

Exemplo
Se eu tenho um SQL que vai me retornar 1 registros quero exibir 50 por
páginas.

obrigado pela atenção

-- 
Sérgio Antônio dos Santos
Bacharel em Sistemas de Informação
(31) 8573-7004

###

Vem aí...
SEARA 2009
21 a 24 de Fevereiro - Campus da UFV - Viçosa - MG

"Alcancei misericórdia e a graça do Senhor foi imensa." (ITm 1, 13b, 14a)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Carga noturna, TXT ou XML?

[crczzampronha]

Uma boa opção é acessar diretamente os dados do firebird usando pljava com
um drive jdbc adequado

2009/2/17 Guilherme Carvalho 

> Estou com uma demanda para ler dados de um outro banco, Firebird, todas as
> noites e trazer para um banco PostgreSQL, neste caso o melhor é ler de um
> arquivo txt ou de um arquivo XML?
>
>
> Atenciosamente
> Guilherme de Carvalho Carneiro.
>
> ___
> 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] Carga noturna, TXT ou XML?

[Guilherme Carvalho]

Ivo, vc teria algum exemplo de como trabalhar desta maneira que vc
apresentou? Lembrando que tenho uma base em Firebird (origem) e outra base
em PostgreSQL (Destino).

2009/2/17 ivo nascimento 

> eu nao recomendaria nenhum dos dois pois implicaria em dois
> processamentos...
> que tal uma aplicacao direta entre os bancos... que alem de facilitar teu
> trabalho, pode ser distribuida em partes menosres sem maiores dores de
> cabeça usando DBI ou dblink, dentro de uma transacao unica fazendo todo o
> trabalho.?
> Mas se a ideia for estritamente performance... muito provavelmente, apesar
> de voce primeiro ter de fazer o arquivo d importação e depois importar, se
> usar os dados de importação da maneira correta, a operação será muito mais
> rapida...
> no formato em que os inserts sao feitos em lote(como um bunk load) isso vai
> ficar show.
>
>
>
>
> 2009/2/17 Guilherme Carvalho 
>
>> Sim. Na verdade não é o banco todo, apenas alguns dados de algumas tabela.
>>
>>
>>
>> On Tue, Feb 17, 2009 at 5:58 PM, Jota  wrote:
>>
>>> Olá,
>>>
>>> Você quer migrar dados toda a noite dados do Firebird para o PG?
>>>
>>> []s
>>>
>>> 2009/2/17 Guilherme Carvalho :
>>>  > Estou com uma demanda para ler dados de um outro banco, Firebird,
>>> todas as
>>> > noites e trazer para um banco PostgreSQL, neste caso o melhor é ler de
>>> um
>>> > arquivo txt ou de um arquivo XML?
>>> >
>>> >
>>> > Atenciosamente
>>> > Guilherme de Carvalho Carneiro.
>>> >
>>> > ___
>>> > pgbr-geral mailing list
>>> > pgbr-geral@listas.postgresql.org.br
>>> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> João Paulo
>>> www.dextra.com.br/postgres
>>> PostgreSQL
>>> ___
>>> 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
>>
>>
>
>
> --
> Ivo Nascimento - Iann
> -
> |   twitter: ivonascimento . |
> |   http://ianntech.com.br.  |
> |   ZCE ID 227463685|
> -
>
> ___
> 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