Re: [pgbr-geral] [pgbr-dev] PGDay PR: Cascavel abraça o Postgres!

2012-08-24 Por tôpico Eduardo Santos
Olá pessoal,

Legal ver o caso. Vocês lembraram de divulgar o Latinoware? Talvez seria
o caso de entrar em contato com os organizadores e pedir um apoio na
divulgação do que vamos fazer em Foz.

Sobre o evento em outros locais, tem 100% de meu apoio.
 
 
-- 
Eduardo Santos
Analista de Sistemas

http://www.eduardosan.com
http://twitter.com/eduardosan

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


[pgbr-geral] Consultoria em monitoramento PostgreSQL com o Cedrus

2012-05-28 Por tôpico Eduardo Santos
Pessoal,

Estamos com uma demanda sobre o Cedrus e tenho dado uma garibada no
código para funcionar nas últimas versões do Rails. Também temos que dar
uma melhorada na documentação, enfim, tornar o software mais apresentável.

Alguém que conheça a plataforma está a fim de prestar um serviço de
consultoria para torná-lo mais apresentável a funcional?

Interessados enviem uma mensagem em PVT para eduardo.san...@lightbase.com.br


-- 
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] ERP livre PostgreSQL Brasil

2012-03-15 Por tôpico Eduardo Santos
Dutra,

Eu utilizo o project-open há algum tempo e acho muito bom, principalmente
para gerências financeiras e de TIC. Dê uma olhada:

http://www.project-open.com/



-- 
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] OFF-TOPIC - Vaga para DBA PostgreSQL

2012-01-10 Por tôpico Eduardo Santos
Gente,

É possível que a oferta de vagas hoje seja baixa, mas tenho certeza que se
criarmos um canal para isso dentro da comunidade e divulgarmos sua
existência as vagas vão aparecer. Imaginem: se alguém precisar de um DBA
PostgreSQL vai saber exatamente para onde mandar. Essa lista poderia ser
moderada com envio aberto, assim se alguém que não fizer parte da lista
quiser enviar o moderador pode decidir se publica ou não.

Mais uma reflexão para fomentar a discussão: que mal tem criar a lista de
vagas? Não haveria uma necessidade grande de armazenamento ou algo assim,
apenas uma lista de e-mail para divulgar as vagas.

Como inspiração, fica a lista PHP Empregos:
http://br.dir.groups.yahoo.com/group/php-empregos/?v=1t=directorych=webpub=groupssec=dirslk=4

Conheço muita gente que conseguiu vaga pela lista.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] OFF-TOPIC - Vaga para DBA PostgreSQL

2012-01-09 Por tôpico Eduardo Santos
Que tal criar a lista PostgreSQL-vagas logo e esperar que as pessoas
comecem a enviar? Alguém?

Em 9 de janeiro de 2012 11:01, JotaComm jota.c...@gmail.com escreveu:

 Opa, seu Flávio

 Em 7 de janeiro de 2012 23:50, Flavio Henrique Araque Gurgel 
 fha...@gmail.com escreveu:

  Olá colegas!
 
  Aproveitando o grande movimento nesta lista, gostaria de anunciar mais
  uma vaga para Analista de Suporte PostgreSQL. Ainda é extra-oficial,
  portanto não foi nem promulgado no site da empresa. Segue abaixo a
  oportunidade:

 (...)

 Não achei nada off-topic :)
 Quem me dera houvessem tantas mensagens de vagas que tivéssemos de
 criar uma lista só pra isso!


 Concordo plenamente com você.


 []s
 Flavio Gurgel
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



 Abraços
 --
 JotaComm
 http://jotacomm.wordpress.com

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




-- 
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Brutal queda de performance atualizando de 8.2 para 8.4

2011-11-12 Por tôpico Eduardo Santos
)
 Index Cond: (acs_objects.object_id =
public.forums_forums.forum_id)
 -  Nested Loop  (cost=0.00..982907.73 rows=397639583 width=4)
(actual time=0.102..1117.157 rows=1396734 loops=67)
   -  Nested Loop  (cost=0.00..12218.50 rows=45973 width=4)
(actual time=0.073..0.487 rows=92 loops=67)
 Join Filter: ((p.privilege)::text =
(pdm.privilege)::text)
 -  Seq Scan on acs_privilege_descendant_map pdm
 (cost=0.00..9.23 rows=3 width=13) (actual time=0.025..0.025 rows=1
loops=67)
   Filter: ((descendant)::text =
'read_private_data'::text)
 -  Nested Loop  (cost=0.00..549.81 rows=281596
width=14) (actual time=0.037..0.364 rows=231 loops=67)
   -  Index Scan using party_member_member_idx on
party_approved_member_map pamm  (cost=0.00..25.68 rows=18 width=4) (actual
time=0.018..0.018 rows=1 loops=67)
 Index Cond: (member_id = 3443)
   -  Index Scan using acs_permissions_grantee_idx
on acs_permissions p  (cost=0.00..28.92 rows=16 width=18) (actual
time=0.015..0.255 rows=231 loops=67)
 Index Cond: (p.grantee_id = pamm.party_id)
   -  Index Scan using acs_obj_ctx_idx_ancestor_idx on
acs_object_context_index c  (cost=0.00..13.14 rows=638 width=8) (actual
time=0.008..6.993 rows=15182 loops=6164)
 Index Cond: (c.ancestor_id = p.object_id)
 SubPlan 1
   -  Index Scan using site_nodes_object_id_idx on site_nodes
 (cost=0.00..8.52 rows=1 width=4) (actual time=0.266..0.268 rows=1 loops=67)
 Index Cond: (object_id = $0)
 Total runtime: *95704.632* ms
(26 registros)


As diferenças entre as decisões tomadas pelo otimizador são tão absurdas
que não sei nem por onde começar.

Será que alguém pode me dar uma luz?

-- 
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Brutal queda de performance atualizando de 8.2 para 8.4

2011-11-12 Por tôpico Eduardo Santos
Olá Dutra,

Obrigado pela resposta. Seguem comentários.

Em 12 de novembro de 2011 12:14, Leandro Guimarães Faria Corcete DUTRA 
l...@dutras.org escreveu:

 Le 2011-N-12  11h38, Eduardo Santos a écrit :


 Estava com alguns problemas de lock


 Que problemas?  Normalmente, a questão não é versão mas programação do
 aplicativo…


É um problema que até a versão 8.1 gerava deadlock no PostgreSQL: uma
função PL/pgSQL, chamada em uma transação, que chama uma outra função
PL/pgSQL em outra transação. Um ciclo de 5 ou 6 funções chamadas dentro de
transações. O problema maior não é esse, contudo. A questão é que a
sequência de funções pode ser chamada várias vezes dentro da aplicação.
Assim, enquanto a tabela está sendo chamada por uma consulta, ela está
travada pela transação. No meio disso tudo, existe uma outra chamada para a
transação, que só vai ser executada após a primeira trava ser liberada.

Difícil de explicar dada a complexidade da chamada, mas o fato é que temos
muitos locks em sequência da mesa linha na mesma tabela. Como essa é a
parte que mais evoluiu, achei quem um upgrade ia me ajudar.

Sim, o aplicativo poderia realizar uma chamada mais atômica de uma única
função PL/pgSQL e resolver o problema, mas estou adiando isso até não ter
mais jeito. O trabalho de reescrita seria simplesmente construir o sistema
novamente, e não posso me dar a esse luxo enquanto o sistema está lento
para os usuários.




  decidi atualizar minha versão do PostgreSQL da 8.2 para a 8.4


 Por que para uma versão tão antiga?  Já estamos na 9.1, que avançou bem
 mais em relação à 8.4 que a 8.4 em relação à 8.2.


Problemas de retro-compatibilidade que ainda não tive tempo de resolver.
Como removeram as cláusulas add_missing_from e regex_flavour na versão 9.0,
ainda não posso atualizar. Também é algo que pode ser resolvido, com tempo
que ainda não tenho. A ideia era resolver após o sistema ficar mais rápido.



  Contudo, para minha surpresa, a performance caiu drasticamente. O
 curioso é que as máquinas físicas são idênticas fisicamente e mantive
 exatamente os mesmos parâmetros de configuração para o PostgreSQL.


 Essas não são as únicas variáveis.  Só de cabeça, sem gastar muito
 fosfato, vêm sistema operacional, sistemas de arquivos e configuração dos
 mesmos; e coleta de estatísticas.


Essa é a questão: as máquinas são fisicamente iguais, com os mesmos
softwares instalados e mesmas configurações de SO. Fiz questão de checar
duas vezes para garantir um ambiente replicado. Até o disco é o mesmo.



Como os planos de execução foram bem diferentes, eu apostaria em
 diferenças ou na estrutura dos dados; ou no texto da consulta; ou na massa
 de dados; ou na configuração do PostgreSQL ou na coleta de estatísticas,
 todos pontos a verificar urgentemente, e informar aqui.


Essa foi a ideia que eu tive. Me parece que houve muitas mudanças no
otimizados. Consegui achar duas referências:

http://postgresql.1045698.n5.nabble.com/query-taking-much-longer-since-Postgres-8-4-upgrade-td3787736.html
http://postgresql.1045698.n5.nabble.com/A-query-become-very-slow-after-upgrade-from-8-1-10-to-8-4-5-td3246107.html

Nenhuma das duas foi conclusiva, contudo. O fato é que o otimizador escolhe
um nested loop com um semi join na versão do 8.4, enquanto no 8.1 a opção
escolhida é primeiro ordenar utilizando um bitmap heap scan. Infelizmente
meus conhecimentos de otimização do otimizador (desculpe o pleonasmo) não
me permitiram resolver o problema ainda. Alguma ajuda com dicas de
configuração seria bem-vinda.

Mais uma vez, obrigado pela resposta em pleno Sabadão! :)


-- 
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Brutal queda de performance atualizando de 8.2 para 8.4

2011-11-12 Por tôpico Eduardo Santos
Olá Osvaldo,

Obrigado pela resposta. Seguem comentários:


 Pelos números apresentados tudo indica que suas estatísticas estavam
 atualizadas o que levou o planejador a optar por caminhos
 ineficientes.
 Veja por exemplo:

 Nested Loop  (cost=0.00..982907.73 rows=397639583 width=4) (actual
 time=0.102..1117.157 rows=1396734 loops=67)

 ele estimou que existiriam 397.639.583 linhas quando, na realidade,
 existiam 1.396.734 linhas.

 Rode novamente sua consulta com as estatísticas atualizadas e avalie o
 resultado.

 A versão que você está utilizando é a 8.4.9?



Eu executei o vacuum full com analyze, rodei novamente a consulta e não
obtive resultados muito diferentes. A versão é a 8.4.9 sim. Seria
necessário executar o vacuum mesmo com o autovacuum ligado?

Também não entendi como ele conseguiu ter resultados tão diferentes entre
duas versão do PostgreSQL, mas aconteceu.


Euler,

Seguem respostas:

8.4.oque?


8.4.9


  Você executou a EXPLAIN ANALYZE várias vezes para se certificar de
 que a diferença de tempo não é por causa de uma partida a frio da versão
 8.4?


Sim, essa foi a primeira coisa que pensei. Executei várias vezes e os
resultados não mudam muito.



 Qual é a consulta?



Desculpe, esqueci de anexar a consulta. É uma consulta realmente feia, mas
que não chegava a ser um desastre no banco:


select forums_forums.package_id,
  acs_object__name(apm_package__parent_id(forums_forums.package_id))
as parent_name,
  (select site_node__url(site_nodes.node_id)
  from site_nodes
  where site_nodes.object_id = forums_forums.package_id) as url,
  forums_forums.forum_id,
  forums_forums.name,

case when last_post  (cast(current_timestamp as date)- 1) then 't'
else 'f' end as new_p

  from forums_forums_enabled forums_forums,
  acs_objects
  where acs_objects.object_id = forums_forums.forum_id and
  forums_forums.package_id in
(0,840191,1486834,626929,520062,1101742,1160464,1161067,2750196,3500360,133998,3673774,3676596,3686932,4860207,5986896,10050612,10157702,4645,93855,3186091,601355,22297512,6552691,21650654,8265465,23731964,33752302,15316177)

  and exists (
  select 1
  from acs_object_party_privilege_map ppm
  where ppm.object_id = forums_forums.package_id
and ppm.party_id = '3443'
and ppm.privilege = 'read_private_data'
  )

   order by parent_name,
   forums_forums.name


Uma das coisas que me chamaram atenção foi a estimativa do índice
 acs_obj_ctx_idx_ancestor_idx. Qual a definição da tabela
 acs_object_context_index?


A definição é a seguinte:

Tabela public.acs_object_context_index
Coluna |  Tipo   | Modificadores
---+-+---
 object_id | integer | não nulo
 ancestor_id   | integer | não nulo
 n_generations | integer | não nulo
Índices:
acs_object_context_index_pk PRIMARY KEY, btree (object_id,
ancestor_id)
acs_obj_ctx_idx_ancestor_idx btree (ancestor_id)
acs_obj_ctx_idx_object_id_idx btree (object_id)
Restrições de verificação:
acs_obj_context_idx_n_gen_ck CHECK (n_generations = 0)
Restrições de chave estrangeira:
acs_obj_context_idx_anc_id_fk FOREIGN KEY (ancestor_id) REFERENCES
acs_objects(object_id)
acs_obj_context_idx_obj_id_fk FOREIGN KEY (object_id) REFERENCES
acs_objects(object_id)


Ela funciona como uma tabela intermediária para facilitar a contagem da
quantidade de filhos que determinado objeto tem. É uma tentativa de evitar
a contagem num subselect,  o que tornaria a consulta ainda mais lenta.

Sabe me dizer se houve alguma mudança significativa no otimizados entre as
versões 8.2 e 8.4?

-- 
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] [OFF-TOPIC] Full Text Search

2010-09-30 Por tôpico Eduardo Santos
Olá Jorge,

Sugiro que vc dê uma olhada na documentação do tsearch:
http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/docs/tsearch2-guide.html

http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/docs/tsearch2-guide.htmlÉ
possível utilizar uma tabela de dicionários, que permite cadastrar
significados similares de palavras.

Dê ainda uma olhada em 'vectors' e 'queries'.

Em 30 de setembro de 2010 11:46, Jorge Vilela jorge.com...@gmail.comescreveu:

 Olá pessoal, desculpem pelo OFF-TOPIC, mas já tentei resolver só no
 postgres e não consegui.

 Estou com um problema e gostaria de saber se alguém pode me ajudar.

 Tenho uma tabela de produtos em PostgreSQL com aproximadamente 5 milhões de
 registros.
 Os usuários fazem buscas complexas, como:
 pneu da rang
 peneus da ranger
 pireli para ran
 ranger pneu
 pneu com câmara para usar na ford ranger

 Hoje utilizo o suporte a FTS do PostgreSQL, porém, não busca meias
 palavras. Se eu troco para o simples ilike o tempo de execução sobe demais,
 deixando o sistema lento e vulnerável.

 Além do suporte à meias palavras, preciso do suporte a sinônimos e
 fonética. Já tentei o FTS do Mysql mas também não resolve.

 Alguém já conseguiu implementar algo semelhante? Já conseguiu utilizar
 Lucene, sphinx, TBGSearch etc (com php, com essas características)?
 Qual solução vocês adotaram?


 Obrigado,
 Jorge Vilela

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




-- 
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Postgres + Hearbeat

2010-09-30 Por tôpico Eduardo Santos
Olá Fabrício,

Sinceramente, não teria a mesma coragem que você para utilizar DRBD +
Heartbeat na partição dos dados. O risco de inconsistência é muito grande,
principalmente por causa so Split Brain (
http://linux-ha.org/wiki/Split_Brain).

Sugiro repensar sua solução para algo próximo do Warm Stand By, seguindo
esse tutorial do João Cosme:
http://joaocosme.wordpress.com/2009/10/30/ha-em-postgresql-warm-stand-by-heartbeat-hapm/

http://joaocosme.wordpress.com/2009/10/30/ha-em-postgresql-warm-stand-by-heartbeat-hapm/Atente-se
ao comentário do Telles sobre os problemas da utilização do NFS para
detectar a queda do banco.

Abraços

Em 30 de setembro de 2010 12:20, gilmarli...@agrovale.com.br escreveu:

 Ola!
 Fiz isto que vc informou abaixo, porem ele não alterou a localização do
 .pid, ele apenas passou a gravar o postmaster.pid alem do local de origem
 dentro de /data passou a tambem ser gravado no local que defeni nesta
 configuração.


  Em 29 de setembro de 2010 20:08, gilmarli...@agrovale.com.br escreveu:
 
 
  Estou utilizando o drbd + hearbeat para ter um postgresql com alta
  disponibilidade, porem quando provoco uma queda do servidor master o
 slave
  entra normalmente, porem o postgresql não inicializa porque exite o
 arquivo
  postmaster.pid dentro do diretório /data que por sua vez veio replicado
 pelo
  drbd.
  O problema ocorre devido o arquivo postmaster.pid ser criado no mesmo
  diretório que esta o data, assim tambem sendo replicado junto com o
 banco.
  Tentei criando um script removendo o postmaster.pid antes do servidor
  secundario subir o postres, porem acontece algumas veses o heartbeat
 enviar
  alguma informação de start, status, que acaba removendo o postmaster.pid
 do
  servidor secundario, e ai quando e necessario eu parar e iniciar o
 serviço
  não existe o postmaster.pid no servidor slave.
  Se alguem tiver alguma sugestão agradeço.
 
 
  Quem sabe colocar o arquivo do PID em outra partição!!! Altere a GUC
  external_pid_file [1] no postgresql.conf.
 
  [1]
 
 http://www.postgresql.org/docs/current/interactive/runtime-config-file-locations.html
 
  --
  Fabrízio de Royes Mello
  Blog sobre TI: http://fabriziomello.blogspot.com
  Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
  ___
  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




-- 
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] PGCON 2010, será em Brasília?

2010-05-24 Por tôpico Eduardo Santos
Olá Gabriel,

Essa questão está sendo discutida em outra lista, a pgbr-dev. Sugiro que
faça a sua pergunta por lá, pois é pertinente à organização da comunidade.

Em 24 de maio de 2010 08:32, GABRIEL DOS SANTOS gabrielworks...@hotmail.com
 escreveu:

  Bom dia a todos da Comunidade,

 Estava sendo discutido a realização do PGCON 2010 em Brasília,
 já foi definido realmente se será em Brasília? E será no Centro de
 Convenções Ulysses Guimarães?
 Já foi definido a data, pois neste ano estamos com planos de levar a nossa
 equipe desenvolvimento
 que estamos formando aqui na empresa.


 Boa semana a todos vocês.


 Gabriel dos Santos.

 --
 POR DIA 63.912 COMPUTADORES SÃO INFECTADOS POR VÍRUS. LEIA DICAS DE
 SEGURANÇA.http://www.microsoft.com/brasil/windows/internet-explorer/features/navegue.aspx?tabid=1catid=1WT.mc_id=1565

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




-- 
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Ajuda pl-tcl

2010-03-15 Por tôpico Eduardo Santos
Olá José Antonio,

Qual a versão do PostgreSQL que você está usando?

Em 15 de março de 2010 16:18, José Antônio (YMAIL) jaen...@ymail.comescreveu:





 Preciso de ajuda para ativar o pltcl no postgres Windows, recebo a mensagem
 could not load library.



 Ta no path ../lib mas não cria a linguavem.

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




-- 
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Contatos em Brasília

2009-05-12 Por tôpico Eduardo Santos
Olá Coronel,

Não se se ficou sabendo, mas tivemos um dia inteiro sobre PostgreSQL em
Brasília, que foi organizado no Ministério do Planejamento, onde trabalho:

http://www.postgresql.org.br/eventos/pgday/df

Se quiser mais informações ou precisar de ajuda em alguma coisa, mande um
e-mail pra mim em PVT que te respondo.

Abraços

2009/5/12 Jefferson A. L. Pita jalp...@gmail.com

 Senhores (as),


Estou em Brasília. Sou do Exército. Estamos precisando desencadear
 uma campanha de massificação do conhecimento sobre o PostGreSQL com os
 nossos técnicos na área de informática.

Sofremos da massificação da cultura Oracle. Queremos inverter este
 processo nocivo.

Desejamos promover uma série de cursos sobre o PostGreSQL, aqui em
 Brasília. Precisamos de instrutores/professores,   que façam parte do
 Projeto PG, para acertarmos uma parceria.


 Cel LEMOS PITA
 (61) 3415-5204
 coronellemosp...@gmail.com
 asse2a...@dct.eb.mil.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] Governo Federal lança novo portal d e Software Livre

2008-04-02 Por tôpico Eduardo Santos
Desculpem, esqueci o OFF-topic.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral