Re: [pgbr-geral] Merlho forma para conectar banco PG com Oracle
2009/11/23 Roberto Murillo Mathias : > cpan[4]> install DBD > Warning: Cannot install DBD, don't know what it is. > Try the command > > i /DBD/ > > to find objects with matching identifiers. > > O oracle está instalado ná máquina e funcionando. > > 2009/11/23 : >> Buenas >> >> tente instalar dessa forma ( tenta instalado antes o sdk do oracle na >> maquina, ja que e necessario para compilacao >> >> abra o shell do cpan >> >> cpan >> install DBI >> install DBD >> install DBI::Oracle >> install DBD::Oracle >> >> []s >> Luiz >> >> >> >>> Então são dois no inferno astral. >>> >>> 2009/11/20 Leonardo Cezar : Bom, eu preciso pedir desculpas pela forma como me expressei. Estou realmente vivendo um inferno astral. Imaginei. Voce precisa instalar o conector para Oracle do DBI: No seu terminal faça: # cpan DBD::Oracle >>> BEGIN failed--compilation aborted at t/70meta.t line 2. >>> t/70meta.t .. Dubious, test returned 2 (wstat 512, 0x200) >>> No subtests run >>> t/80ora_charset.t ... Can't locate Test/More.pm in @INC (@INC >>> contains: /root/.cpan/build/DBD-Oracle-1.23-Yimm1t/blib/lib >>> /root/.cpan/build/DBD-Oracle-1.23-Yimm1t/blib/arch >>> /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi >>> /usr/local/lib/perl5/site_perl/5.10.0 >>> /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi >>> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl >>> /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi >>> /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl .) at t/80ora_charset.t >>> line 10. >>> BEGIN failed--compilation aborted at t/80ora_charset.t line 10. >>> t/80ora_charset.t ... Dubious, test returned 2 (wstat 512, 0x200) >>> No subtests run >>> >>> Este erro se repete várias vezes e depois : >>> >>> Test Summary Report >>> --- >>> t/01base.t (Wstat: 512 Tests: 0 Failed: 0) >>> Non-zero exit status: 2 >>> Parse errors: No plan found in TAP output >>> t/10general.t (Wstat: 512 Tests: 0 Failed: 0) >>> Non-zero exit status: 2 >>> Parse errors: No plan found in TAP output >>> t/12impdata.t (Wstat: 512 Tests: 0 Failed: 0) >>> >>> Este >>> ___ >>> 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 >> > > > > -- > Roberto Murillo Mathias Costa Junior. > Infowave - Consultoria em TI. > www.infowave.com.br > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > O erro do primeiro stack trace ta dizendo que você não tem o Test::More instalado. cpan Test::More e depois cpan DBD::Oracle ;) -- twitter.com/giulianisanches giulianisanches.blogspot.com github.com/khaoz ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Select
2009/11/12 B i l l : > Boa tarde pessoal! > to com uma dúvida. > SELECT > distinct contas_pagar.cod_cpagar, > contas_pagar.codfornecedor, > contas_pagar.codfuncionario, > contas_pagar.valortotal_cpagar, > contas_pagar.situacao_cpagar > FROM > contas_pagar > JOIN parcela_cpagar ON (parcela_cpagar.cod_cpagar = contas_pagar.cod_cpagar) > > pergunta: > tem com trazer nessa consulta o nome do fornecedor ou do funcionário, > quando tiver o codigo do fornecedor ou do funcionário ? > grato. > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > usa left join na tabela de fornecedor e left join na tabela de funcionário -- twitter.com/giulianisanches giulianisanches.blogspot.com github.com/khaoz ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Erro em function:
Boa noite. Eu tenho uma trigger cujo objetivo é fazer uma verificação de periodo em uma tabela temporal. A idéia é que durante uma edição (ou uma inserção com id igual a um já existente) eu não possa informar um intervalo de datas conflitante com um já existente. A trigger esta abaixo: CREATE OR REPLACE FUNCTION f_check_temporal_constraint() RETURNS TRIGGER AS $$ DECLARE check_id integer; BEGIN IF NEW.tt_ini => NEW.tt_fim THEN RAISE EXCEPTION 'Período inválido: ' 'A data inicial é maior ou igual a data final!'; END IF; -- a inserção de um novo registro com novo id é permitida sem problemas IF NEW.id IS NULL THEN RETURN NULL; END IF; EXECUTE 'SELECT TOP 1 id FROM $TG_TABLE_NAME$ WHERE ' || '(NEW.id <> id) OR ' || '(NEW.tt_ini < tt_ini OR NEW.tt_ini >= tt_fim) AND ' || '(NEW.tt_fim <= tt_ini OR NEW.tt_fim > tt_fim) AND NOT ' || '(NEW.tt_ini <= tt_ini AND NEW.tt_fim => tt_fim)' INTO check_id; IF check_id = NEW.id THEN RAISE EXCEPTION 'Período inválido: Informações em conflito ' 'com registro existente.'; END IF; END $$ LANGUAGE plpgsql; CREATE TRIGGER t_check_temporal_constraint BEFORE INSERT OR UPDATE ON minha_tabela FOR EACH ROW EXECUTE PROCEDURE f_check_temporal_constraint(); Porém ao utilizar ela (pois quero testar ver se a lógica esta correta) e tentar inserir um registro recebo o seguinte erro: ERROR: operator does not exist: timestamp without time zone => timestamp without time zone LINE 1: SELECT $1 => $2 ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. QUERY: SELECT $1 => $2 CONTEXT: PL/pgSQL function "f_check_temporal_constraint" line 4 at IF Sem a trigger os valores são inseridos corretamente. -- twitter.com/giulianisanches giulianisanches.blogspot.com github.com/khaoz ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Problema com campo do tipo timestamp without time zone
Ontem tentei dar um insert (via psql) em uma tabela que possui um
campo do tipo timestamp without time zone e recebi o seguinte erro:
"operator does not exist: timestamp without time zone => timestamp
without time zone"
O comando executado foi:
INSERT INTO minha_tabela(campo_data) values ('string');
Na 'string' eu tentei utilizar o formato mdy, ymd, dmy separados por
'-' ou '/', utilizando ou não a informação de hora (com e sem segundo
e milisegundos). Testei também utilizando com timestamp da seguinte
forma:
(timestamp 'string')
Porém sempre recebi o erro acima.
Qual a forma correta de trabalhar com esse tipo de dado ?
[]'s
--
twitter.com/giulianisanches
giulianisanches.blogspot.com
github.com/khaoz
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] [OFF-TOPIC] Modelagem de controle de d e km e média em relação a entregas, ser viços e despesas
Boa tarde. Apontei o assunto com off-topic pois não sei se o escopo da lista cobre a minha pergunta e dessa forma a galera que não gosta de off pode simplesmente deletar a mensageam sem ler. :) Estou trabalhando com django e cheguei em um módulo onde preciso controlar o km percorrido durante uma entrega e horas de máquina durante um serviço. Ao lançar a despesa também será controlado km / hora e se for um abastecimento, a média. Atualmente tenho os models: Veiculos VeiculosKm(Veiculos) VeiculosHora(Veiculos) Entrega (master) DetalhamentoEntrega (detail) Serviço Despesa (master) DetalhamentoDespesa (detail) Os models VeiculosKm e VeiculosHora possuem apenas uma campo id que aponta para veículos e veículos possui um campo onde eu informo o tipo. Como eu estava fazendo: Nas tabelas de entrega serviço e despesa eu tinha os campos de km inicial, final e percorrido, hora inicial, final e percorrida, e media por hora e km. Na entrega e serviço, conforme eu selecionava o veículo, determinados campos apareciam ou não e nas despesas, durante o detalhamento se fosse informado um abastecimento eu atualizava o campo de média na master. Agora que estou repaginando o sistema resolvi dar uma melhorada nisso pois não me pareceu bom, porém não estou conseguindo fechar uma boa idéia. Pensei em criar duas tabelas ControleKm e ControleHora e relacionar ela as entregas, serviços e despesas, numa relação 1 para 1 e conforme o veículo selecionado uma das tabelas seria preenchida. Para a média, colocar um campo na despesa e quando fosse informado um abastecimento no detalhamento a média seria calculada automaticamente na tabela master. Mas tudo isso me pareceu mascarar o problema que eu tinha antes, simplesmente retirando os campos das tabelas e criando duas para isso. Se alguém tiver sugestões ou me disser "essa forma não esta errada", eu agradeço :) []'s -- twitter.com/giulianisanches giulianisanches.blogspot.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Upgrade do banco de 8.1 para 8.2 e perda de triggers
Bom pessoal, com servidor rodando e tudo mais, o pessoal da software house se encarregou de gerar o backup do XP (pgsql 8.1) e restaurar no Linux (pgsql 8.2). Para isso utilizaram o pgadmin3. Hoje recebo um e-mail, devido a um problema ocorrido no sistema, afirmando que durante a restauração do banco algumas triggers foram perdidas e por isso determinadas rotinas não estavam funcionando corretamente. E ai eu pergunto: 1) É possível que durante o processo de restore as triggers tenham sido ignoradas devido a versão do banco ? 2) O pgadmin3 informaria sobre qualquer erro ao restaurar o banco ? Ou, se as triggers não foram restauradas por algum erro, o mesmo é disparado silenciosamente ? 3) É possível durante uma rotina de backup e restore utilizando o pgadmin3, ignorar elementos como triggers ? :) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgresql no slackware 12 lento
Axo que a discussão toda girou em torno de indices, vacuum e etc. mas o problema provavelmente era outro: Módulos da controladora SATA. Botei o ubuntu e tudo esta funcionando agradavelmente normal. Teria que fazer uns teste novamente com o slack compilando o kernel, mas como estou com prazo estourado fica a dica. Em 31/03/08, Leandro DUTRA<[EMAIL PROTECTED]> escreveu: > 2008/3/31, Sebastian SWC <[EMAIL PROTECTED]>: > > > On Fri, Mar 28, 2008 at 11:57 PM, Euler Taveira de Oliveira > > <[EMAIL PROTECTED]> wrote: > > > Leandro DUTRA wrote: > > > > > > > Mas foi o ext3fs com journalling somente de metadados? > > > > > > > Sim. Utilizei a opção 'writeback' no ext3 e a configuração padrão do > xfs > > > (que tem um 'journaling' semelhante ao 'writeback' do ext3). > > > > Leandro e Euler, > > Qual seria o aconselhado a utilizar: ext3 c/ journaling p/ metadados ou > xfs? > > > De acordo com o Euler — e quando falo genericamente nos 'gurus da > lista', se ele não é _o_ maior guru certamente é um deles —, xfs. > > Isso dito, estou por fora: o xfs está no nível de maturidade e suporte > (ferramentas &c) do ext3fs? Não duvidando que esteja, é uma pergunta > sincera e clara sem querer passar recado algum. > > Outra pergunta: Euler, esse teu teste foi já replicado por outras > pessoas em outras situações? Tem um resumo publicado? > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] > +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 > +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] > ___ > > 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] Postgresql no slackware 12 lento
Apenas adicionando mais dados (apesar de ter dito que tinha encerrado hehehehe): Agora com xfs e mais alguns ajustes no postgresql.conf a coisa melhorou um pouco. Também conferi os indices: Eles existem e são os mesmos da máquina com XP. Em 28/03/08, Leandro DUTRA<[EMAIL PROTECTED]> escreveu: > 2008/3/28, Euler Taveira de Oliveira <[EMAIL PROTECTED]>: > > > Leandro DUTRA wrote: > > > > > XFS não vai te ganhar nada. Um ext3fs com journalling somente de > > > metadados é suficiente. > > > > > Ai que você se engana. O XFS teve um ganho de ~3% em relação ao EXT3 em > > testes com 8.2. > > > Então dou a mão à palmatória! > > Mas foi o ext3fs com journalling somente de metadados? > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] > +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 > +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] > ___ > > 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] Postgresql no slackware 12 lento
> Leando DUTRA: > Você também acredita em Papai Noel? Agora cabou com minha infância :D :P > Marcelo Costa: > Sem flames, eu uso Slackware em servidores de produção com 2TB de dados, > serve ? > Como o Euler disse seus problemas são outros tudo é linux e funciona > bem, depende de quem usa você tem problema de indices entre outros. > Este post acabou para mim. Para mim também. Já tem informação suficiente para que eu possa achar a solução. Agradeço a todos mais uma vez e pelo desculpas por qqer "noobice", esse é o primeiro server rodando pgsql que instalo (e a primeira vez que tenho um contato mais profundo com o banco). []'s a todos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgresql no slackware 12 lento
Bom, eu agora vou tentar meter um XFS na máquina e como último recurso, compilar um kernel pois no canal do slack levantaram a possibilidade de ter um módulo errado carregado para meu HD sata. Vamos ver os resultados. Em 28/03/08, Giuliani Deon Sanches<[EMAIL PROTECTED]> escreveu: > Eu separei em duas partes o post que fiz: > A parte de COMANDOS são os comandos sql que forma executados e na > parte EXPLAIN ANALYZE os resultados. > Aquela parte de comandos são os selects que o programa faz quando eu > digito o código da empresa, unidade e usuário na tela de login no lado > cliente. (ele da output no terminal). Ali tem os tempos que cada > operação esta levando. > O EXPLAIN ANALYZE foi executado direto no servidor. > Quanto a falta de indices, não da pra entender pois o cara fez um > backp no pgadminIII na máquina windows e restaurou ele no server > linux. E se tem possibilidade de fazer os backups sem os indices, com > o tempo de mercado que eles tem com esse sistema, posso afirmar que > ele não optou por isso. > Quanto a questão do linux, concordo, é tudo igual em certos aspectos. > Apenas comentei o que o sujeito falou para ver se alguém tinha > experiência em algum tipo de diferença nesse sentido. > > 2008/3/28, Thiago Risso <[EMAIL PROTECTED]>: > > > == > > > COMANDOS > > > == > > > > Como os amigos já citaram... Foi muito confuso > > > > Tenta mostrar assim : > > > > trisso=# EXPLAIN ANALYZE SELECT relname FROM pg_class; > > QUERY PLAN > > --- > > Seq Scan on pg_class (cost=0.00..7.04 rows=204 width=64) (actual > > time=0.013..0.166 rows=212 loops=1) > > Total runtime: 0.270 ms > > (2 registros) > > > > Obviamente, você coloca todos os selects necessários em AMBOS os > > SERVIDORES > > > > Mas .. de ANTEMÃO , o que deu pra notar é que falta INDICES ! > > > > -- > > Att: > > Thiago Risso > > ___ > > 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] Postgresql no slackware 12 lento
Eu separei em duas partes o post que fiz: A parte de COMANDOS são os comandos sql que forma executados e na parte EXPLAIN ANALYZE os resultados. Aquela parte de comandos são os selects que o programa faz quando eu digito o código da empresa, unidade e usuário na tela de login no lado cliente. (ele da output no terminal). Ali tem os tempos que cada operação esta levando. O EXPLAIN ANALYZE foi executado direto no servidor. Quanto a falta de indices, não da pra entender pois o cara fez um backp no pgadminIII na máquina windows e restaurou ele no server linux. E se tem possibilidade de fazer os backups sem os indices, com o tempo de mercado que eles tem com esse sistema, posso afirmar que ele não optou por isso. Quanto a questão do linux, concordo, é tudo igual em certos aspectos. Apenas comentei o que o sujeito falou para ver se alguém tinha experiência em algum tipo de diferença nesse sentido. 2008/3/28, Thiago Risso <[EMAIL PROTECTED]>: > > == > > COMANDOS > > == > > Como os amigos já citaram... Foi muito confuso > > Tenta mostrar assim : > > trisso=# EXPLAIN ANALYZE SELECT relname FROM pg_class; > QUERY PLAN > --- > Seq Scan on pg_class (cost=0.00..7.04 rows=204 width=64) (actual > time=0.013..0.166 rows=212 loops=1) > Total runtime: 0.270 ms > (2 registros) > > Obviamente, você coloca todos os selects necessários em AMBOS os > SERVIDORES > > Mas .. de ANTEMÃO , o que deu pra notar é que falta INDICES ! > > -- > Att: > Thiago Risso > ___ > 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] Postgresql no slackware 12 lento
Executei um VACUUM ANALYZE antes dos EXPLAIN ANALYZE para postar para vocês.
Apenas uma adendo ao que foi discutido: O desenvolvedor desse sistema
garante que se eu colocar um fedora ou ubuntu o resultado vai ser bem
mais rápido. Sinceramente não sei qual a influência mas em pesquisas
pelo google achei algumas referências sobre lentidão do pgsql no slack
e um bom funcionamento dele em fedora/ubuntu. Segue os comandos
executados e resultados, deixando claro que o banco é o mesmo, com a
mesma qtde de registros sendo que agora o do server linux tem um
VACUUM ANALYZE a seu favor:
==
COMANDOS
==
[27/03/2008 20:37:08] - Transacao 0: BEGIN
[27/03/2008 20:37:08] - T0 {
SELECT id FROM tabemp
WHERE cod = 1;}
[27/03/2008 20:37:08] - Transacao 0: COMMIT [69 ms]
[27/03/2008 20:37:08] - Transacao 1: BEGIN
[27/03/2008 20:37:08] - T1 {
SELECT * FROM tabemp
WHERE id = '1';}
[27/03/2008 20:37:08] - T1 {
SELECT * FROM ctbestplc
WHERE id = '001/001/1';}
[27/03/2008 20:37:08] - Transacao 1: COMMIT [285 ms]
[27/03/2008 20:37:08] - Transacao 5: BEGIN
[27/03/2008 20:37:08] - T5 {
SELECT * FROM tabuni
WHERE id = '001/1';}
[27/03/2008 20:37:08] - Transacao 5: COMMIT [55 ms]
[27/03/2008 20:37:11] - Transacao 7: BEGIN
[27/03/2008 20:37:11] - T7 {
SELECT * FROM tabuni
WHERE id = '001/1';}
[27/03/2008 20:37:11] - Transacao 7: COMMIT [282 ms]
=
EXPLAIN ANALYZE
=
BEGIN
QUERY PLAN
Seq Scan on tabemp (cost=0.00..1.01 rows=1 width=2) (actual
time=0.013..0.014 rows=1 loops=1)
Filter: (cod = 1)
Total runtime: 0.086 ms
(3 rows)
COMMIT
BEGIN
QUERY PLAN
--
Seq Scan on tabemp (cost=0.00..1.01 rows=1 width=432) (actual
time=0.011..0.012 rows=1 loops=1)
Filter: ((id)::text = '1'::text)
Total runtime: 0.067 ms
(3 rows)
COMMIT
BEGIN
QUERY PLAN
Seq Scan on ctbestplc (cost=0.00..1.01 rows=1 width=79) (actual
time=0.013..0.014 rows=1 loops=1)
Filter: ((id)::text = '001/001/1'::text)
Total runtime: 0.042 ms
(3 rows)
COMMIT
BEGIN
QUERY PLAN
--
Seq Scan on tabemp (cost=0.00..1.01 rows=1 width=432) (actual
time=0.010..0.011 rows=1 loops=1)
Filter: ((id)::text = '1'::text)
Total runtime: 0.056 ms
(3 rows)
id | dt_inc| id_usu_inc | dt_alt|
id_usu_alt | id_emp | cod |nome | estrutura |
gerar_cod_red | proximo_codigo_gerado
---+-++-+++-+-+---+---+---
001/001/1 | 2008-02-06 14:30:55 | 001/1 | 2008-02-06 14:30:55 |
001/1 | 1 | 101 | PLANO PADRAO MERITO | 111222|
1 | 220
(1 row)
COMMIT
BEGIN
QUERY PLAN
--
Seq Scan on tabuni (cost=0.00..1.01 rows=1 width=767) (actual
time=0.016..0.017 rows=1 loops=1)
Filter: ((id)::text = '001/1'::text)
Total runtime: 0.126 ms
(3 rows)
COMMIT
BEGIN
QUERY PLAN
--
Seq Scan on tabuni (cost=0.00..1.01 rows=1 width=767) (actual
time=0.010..0.011 rows=1 loops=1)
Filter: ((id)::text = '001/1'::text)
Total runtime: 0.079 ms
(3 rows)
COMMIT
2008/3/27, Osvaldo Rosario Kussama <[EMAIL PROTECTED]>:
> Joao escreveu:
>
> > rode um vaccum no teu slack
> > Podem ter muitas dead pages!!
>
>
>
>
> Ou, melhor ainda, um VACUUM ANALYZE pois as estatísticas - utilizadas
> pelo planejador - podem estar desatualizadas.
>
>
> Osvaldo
>
> ___
> 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] Postgresql no slackware 12 lento
Ok, irei postar os resultados das análises a noite (ontem eu acabei aprendendo o uso hehehe) Realmente, o fs do windows é lamentável e logo não deveria estar tão mais rápido que o linux. Te garanto que no meu server slack tem pouquíssimos processos rodando. O mais pesado o pgsql. E ambos possuem a mesma quantidade de registros. E antes de mais nada, muito obrigado pelo interesse e ajuda de todos. 2008/3/27, Sebastian SWC <[EMAIL PROTECTED]>: > 2008/3/27 Joao <[EMAIL PROTECTED]>: > > > Sinceramente não acho que essa questão de file system seja a causa mesmo pq > > o filesystem do windows pelo amor de deus! > > Por que nao? todo mundo fala que o armazenamento do windows eh precario... > > > -- > > 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 > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgresql no slackware 12 lento
Estou medindo o tempo que leva quando o cara digita 1 no aplicação no lado cliente, por exemplo, e o servidor retorna o nome associado a esse 1. Diogo: Eu não sou muito hábil com o pgsql. Poderia exemplificar como analisar os planos de execução ? Marcelo: 1 - Fiz algumas analises parciais e no servidor mesmo (que agora esta aqui comigo). O tempo lá de um dos selects mais demorados gira na casa do 109ms enquanto aqui na minha máquina fica em 209ms (as vezes mais). 2 - Abri o firewall mas o tempo persiste. Problemas de rede acho pouco provável pois agora estou em casa, com estrutura diferente e os tempos são os mesmos. Porém observei um detalhe: Os maiores tempos de respostas ocorrem em queries que possuem na clausula where algo como: where id = '001/01' ou where id = '001/001/1' Parece que quando vai fazer uma procura por string ele pesa. Como é um programa feito em java e quando executado pelo terminal ele vai dando output de todos os selects feitos estou conseguindo acompanhar muitos passos. A maioria das queries são executadas em 2, 3 máximo de 6 ms. Mas tem umas que vão de 200 a 600 ms. Essas são as que procuram por strings semelhantes as que passei acima. Em 26/03/08, Marcelo Costa<[EMAIL PROTECTED]> escreveu: > Giuliani Deon Sanches wrote: > > Mais um detalhe: Eu comparei os dois postres.conf e estavam identicos... > > > > Em 26/03/08, Giuliani Deon Sanches<[EMAIL PROTECTED]> escreveu: > > > >> 1 - Em ambas as situações é apenas um HD. Concordo com o que você > >> falou, porém o hardware foi comprado e me passado. Não pude opinar no > >> processo :( > >> 2 - O HD é novo, não acho que possa ser a causa do problema. Em > >> comparação com o HD windows, sim, são semelhantes. > >> 3 - Vou dar uma olhada nos logs > >> > > 1. Faz assim, verifica o plano de execução destas consultas com EXPLAIN > ANALIZE e posta aqui, tanto no windows quanto no linux. > > 2. Como dito antes se o tempo de resposta estiver lento no cliente ai vc > pode ter problemas de rede com este servidor, como vc disse que > habilitou um firewall, você já tentou desligar o firewall neste server e > executar o mesmo teste ? > > Att, > > > Marcelo Costa. > > ___ > 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] Postgresql no slackware 12 lento
Mais um detalhe: Eu comparei os dois postres.conf e estavam identicos... Em 26/03/08, Giuliani Deon Sanches<[EMAIL PROTECTED]> escreveu: > 1 - Em ambas as situações é apenas um HD. Concordo com o que você > falou, porém o hardware foi comprado e me passado. Não pude opinar no > processo :( > 2 - O HD é novo, não acho que possa ser a causa do problema. Em > comparação com o HD windows, sim, são semelhantes. > 3 - Vou dar uma olhada nos logs > > Em 26/03/08, Marcelo Costa<[EMAIL PROTECTED]> escreveu: > > > Bom, eu utilizo Slackware em meus servidores de banco de dados com > > PostgreSQL compilado, com tuning, core 2 duo, e 2GB. > > > > > > Giuliani Deon Sanches wrote: > > > Instalei um pgsql compilado no slack 12. Meti um iptables fechando > > > tudo e deixando aberto apenas entrada e saida da 5432. > > > As únicas configurações que fiz foi para habilitar conexões da rede > > > local pois esperava que o pessoal que desenvolve o software que vai > > > utilizar esse servidor tivesse definições próprias. > > > Descobri que o máximo que eles manjam de postgresql é a instalação via > > > next-next-finish e tem muitos clientes deles rodando o pgsql no XP. > > > Hoje a tarde recebi uma ligação onde eles afirmaram que se eles > > > colocarem o pgsql em uma máquina XP de lá (512 de ram) ela esta > > > rodando (respondendo) mais rapidamente do que o servidor dedicado ao > > > pgsql (1GB de ram, dual core). Acho que a versão windows já vem com > > > alguma pré-configuração que permite essa performance melhor. > > > Além das informações nesse link > > > (http://www.westnet.com/~gsmith/content/postgresql/pg-5minute.htm) o > > > que mais eu precisaria verificar para obter um bom desempenho do pgsql > > > nesse server, considerando que o sistema de arquivos e ext3 ? > > > > > > > Vários fatores podem influenciar para isso, mas eu duvido que seja o > > tipo de partição, já utilizei Riserfs, Ext3 e XFS. > > > > Perguntas: > > 1. Quantos HDs você utiliza para o Banco de Dados, o recomendado é que > > você separe dados de indices. > > 2. Será que seu HD não tem problemas ? Isso pode ser um fator que gera > > lentidão. Alias o HD do servidor Linux é semelhante ao do servidor > > windows, ou seja, em ambos o hardware é SATA ? > > 3. Ligue os logs do SGDB e procure ver se não há nenhum parametro sendo > > sinalizado que precise de ajuste. > > > > Att, > > > > > > Marcelo. > > > > ___ > > 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] Postgresql no slackware 12 lento
1 - Em ambas as situações é apenas um HD. Concordo com o que você falou, porém o hardware foi comprado e me passado. Não pude opinar no processo :( 2 - O HD é novo, não acho que possa ser a causa do problema. Em comparação com o HD windows, sim, são semelhantes. 3 - Vou dar uma olhada nos logs Em 26/03/08, Marcelo Costa<[EMAIL PROTECTED]> escreveu: > Bom, eu utilizo Slackware em meus servidores de banco de dados com > PostgreSQL compilado, com tuning, core 2 duo, e 2GB. > > > Giuliani Deon Sanches wrote: > > Instalei um pgsql compilado no slack 12. Meti um iptables fechando > > tudo e deixando aberto apenas entrada e saida da 5432. > > As únicas configurações que fiz foi para habilitar conexões da rede > > local pois esperava que o pessoal que desenvolve o software que vai > > utilizar esse servidor tivesse definições próprias. > > Descobri que o máximo que eles manjam de postgresql é a instalação via > > next-next-finish e tem muitos clientes deles rodando o pgsql no XP. > > Hoje a tarde recebi uma ligação onde eles afirmaram que se eles > > colocarem o pgsql em uma máquina XP de lá (512 de ram) ela esta > > rodando (respondendo) mais rapidamente do que o servidor dedicado ao > > pgsql (1GB de ram, dual core). Acho que a versão windows já vem com > > alguma pré-configuração que permite essa performance melhor. > > Além das informações nesse link > > (http://www.westnet.com/~gsmith/content/postgresql/pg-5minute.htm) o > > que mais eu precisaria verificar para obter um bom desempenho do pgsql > > nesse server, considerando que o sistema de arquivos e ext3 ? > > > > Vários fatores podem influenciar para isso, mas eu duvido que seja o > tipo de partição, já utilizei Riserfs, Ext3 e XFS. > > Perguntas: > 1. Quantos HDs você utiliza para o Banco de Dados, o recomendado é que > você separe dados de indices. > 2. Será que seu HD não tem problemas ? Isso pode ser um fator que gera > lentidão. Alias o HD do servidor Linux é semelhante ao do servidor > windows, ou seja, em ambos o hardware é SATA ? > 3. Ligue os logs do SGDB e procure ver se não há nenhum parametro sendo > sinalizado que precise de ajuste. > > Att, > > > Marcelo. > > ___ > 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] Postgresql no slackware 12 lento
Fui lá no cliente verificar. A demora em consulta ocorre, por exemplo: O cara digita um código para retornar um nome. Quando estou logado no windows XP a processo ocorre em 1s. Quando mudo para o servidor linux esse mesmo processo leva de 2 a 3s (em determinadas operações aumenta). Tentei passar o parametro data=ordered (ou writeback) no fstab para fazer journal somente do metadados porém não obtive melhorias. Também coloquei o shared_buffers em 150Mb e o effective_cache_size em 512Mb sem resultados. Considerando tudo isso, o problema é realmente o ext3 ? (eu não consigo aceitar que um xp com 512 responda mais rápido que um slack com pg compilado para 686 com 1gb de ram) Em 26/03/08, Joao<[EMAIL PROTECTED]> escreveu: > reiserfs é bom para arquivos menores do que o o tamanho de 1 block., ou seja > arquivos pequenos Se eu não me engano isso é devido ao algoritmo chamado > balanced trees, na versao 4 ja implementa o dancing trees. Mas de qualquer > forma o reiser é bom para arquivos pequenos!!! > > - Original Message - > From: "Sebastian SWC" <[EMAIL PROTECTED]> > To: "Comunidade PostgreSQL Brasileira" > Sent: Wednesday, March 26, 2008 6:17 PM > Subject: Re: [pgbr-geral] Postgresql no slackware 12 lento > > > 2008/3/26 Leandro DUTRA <[EMAIL PROTECTED]>: > > 2008/3/26, Leandro Augusto Kisielewicz <[EMAIL PROTECTED]>: > > > > > Não se deve usar sistema de arquivo com journaling para postgres... vc > > > deve > > > desabilitar o journaling do seu ext3... pq o postgres já faz isso > > o certo > > > é deixar o teu diretório de dados do postgres em uma partição com um > > sistema > > > de arquivos q não tenha esta característica ou que esteja > > desabilitada > > > > Detalhe: o journaling de metadados é útil e não atrapalha. É o de > > dados que dever ser desabilitado. > como funciona esse "journaling do postgres"? > > > Portanto, o ext3 deve ser usado, mas apenas com journaling de metadados. > Alguma ideia de como se faz isso? > > reiserfs e uma uma pessima ideia? > > -- > 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 > > ___ > 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] Postgresql no slackware 12 lento
Instalei um pgsql compilado no slack 12. Meti um iptables fechando tudo e deixando aberto apenas entrada e saida da 5432. As únicas configurações que fiz foi para habilitar conexões da rede local pois esperava que o pessoal que desenvolve o software que vai utilizar esse servidor tivesse definições próprias. Descobri que o máximo que eles manjam de postgresql é a instalação via next-next-finish e tem muitos clientes deles rodando o pgsql no XP. Hoje a tarde recebi uma ligação onde eles afirmaram que se eles colocarem o pgsql em uma máquina XP de lá (512 de ram) ela esta rodando (respondendo) mais rapidamente do que o servidor dedicado ao pgsql (1GB de ram, dual core). Acho que a versão windows já vem com alguma pré-configuração que permite essa performance melhor. Além das informações nesse link (http://www.westnet.com/~gsmith/content/postgresql/pg-5minute.htm) o que mais eu precisaria verificar para obter um bom desempenho do pgsql nesse server, considerando que o sistema de arquivos e ext3 ? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta entre datas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 se entendi bem: select ID from TABELA where PARAMETRO between DATA1 and DATA2. Leandro Soares escreveu: > Amigos, > > tenho uma tabela com dois campos timestamp e gostaria de de consultar se > uma determinada data está neste intervalo dos campos, exemplo: > > Tabela_1 => ID int8 > DATA1 timestamp > DATA2 timestamp > > ID DATA1 DATA2 >101/01/200703/01/2007 >204/01/200705/01/2007 >302/01/200706/01/2007 > > Tenho que retornas as ID´s que estão no período de 02/01 a 03/01, que no > exemplo acima são as ID´s 1 e 3. Como ficaria esse SQL ?? > > > um abraço, > > Leandro Soares > > > > __ > Fale com seus amigos de graça com o novo Yahoo! Messenger > http://br.messenger.yahoo.com/ > > > > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral - -- Khaoz (Giuliani Deon Sanches) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGQ6pVz++p7i3Bo4IRAsc6AJ0bSsQN0Q3IayKVx0J4pI/R/eYt5gCbB2K+ LR/y6G988d6pQo64sArADj4= =I8ux -END PGP SIGNATURE- ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
