Re: [pgbr-geral] Apoio Técnico

2011-11-16 Por tôpico Fernando Ike


On 15-11-2011 14:42, Bruno Silva wrote:
 Pra você terem idéia, segue um trecho.
 Para esclarecer suas duvidas sobre o ambiente ... preços estimados do
 Oracle, razoes para não usar o PostGre e tudo o mais que você precise
 saber sobre tecnologia. 

 O cara não sabe nem o nome do banco, que dirá usá-lo.
 Detalhe, ainda não teve nem a publicação da licitação.
[...]

   É um FUD![1] Combater FUD não se vence somente com argumentos 
técnicos ou casos

   Decisões baseadas em FUD revelam a pouca maturidade quando pensa TI 
num empresa/instituição. Para combater deve-se usar um pouco mais do 
que preço, pessoal, culpar empresa, etc.

   Erros se cometem com PostgreSQL, Oracle, etc. O que pode argumentar 
que um problema com uma tecnollogia é um pouco mais do culpar a tecnologia.

   TI funcionar bem, precisa-se que os gestores/donos/etc. tenha a 
ciência que TI é parte operacional da empresa. Quanto mais preparada o 
corpo técnico ou prestador de serviço melhor será o custo operacional 
da empresa. Nessa abordagem pode usar as siglas ITIL, COBIT, governança, 
etc.

   O PostgreSQL tem um custo inicial baixo, manutenção médio e um 
retorno de investimento alto à longo prazo. Os bancos SQL proprietário 
tem um custo inicial alto, manutenção médio para alto e um retorno de 
investimento baixo à longo prazo.

   Certeza que é dificílimo encontrar uma empresa realmente boa 
(tecnicamente e custo satisfatório) por aí.




dois centavos,
-- 
Fernando Ike
http://midstorm.org/~fike/weblog
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Problemas com o catálogo do PostgreSQL

2011-11-16 Por tôpico Rogério Grando
Olá pessoal,
Estive em umas das palestras do PgBr deste ano  “Estatísticas e monitoramento e 
diagnósticos através do catalogo do PostgreSQL” e expus um problema que havia 
ocorrido na mesma semana referente a catálogo, demorei um pouco para postar 
porque estava tentando simular novamente o problema.
Informações:
SO: Ubuntu Server, mas fiz um teste no Win e também tive o problema, acho que 
independe do SO.
PostgreSQl: 8.3.5 compilado.
Echema: Public
Encodig UTF8

Quando é executado o passo 4, alterando o tipo do campo, a ligação b.attrelid = 
a.relfilenode deixa de ser verdadeira, b.attrelid muda de valor. Assim o select 
passo 5 que é igual ao passo 3 não encontra mais o registro.
Fiz algum teste de renomear a coluna e o mesmo não ocorre, aparentemente isso 
acontece apenas quando altero o tipo de dados. Obs. A mesma situação ocorre na 
versão 9.1.
Não sei se é forma em que consulto o catálogo que está incorreta, e se alguém 
já passou por esse tipo de problema.
Agradeço pela habitual cordialidade que sempre tive na lista.

-- 1º
CREATE DATABASE rteste
  WITH OWNER = postgres
   ENCODING = 'UTF8'
   TABLESPACE = pg_default
   CONNECTION LIMIT = -1;

-- 2º
CREATE TABLE tab_teste
(
  co_coluna numeric
)
WITH (
  OIDS=FALSE
);
ALTER TABLE tab_teste OWNER TO postgres;

-- 3º Encontra tabela e campo
SELECT a.relname AS Tabela, b.attname AS Campo
FROM pg_class a 
JOIN pg_attribute b ON  b.attrelid = a.relfilenode
WHERE  a.relname = 'tab_teste' AND b.attname = 'co_coluna';

-- 4º Provoca o problema
ALTER TABLE tab_teste ALTER COLUMN co_coluna TYPE double precision;

-- 5º Não encontra mais tabela e campo
SELECT a.relname AS Tabela, b.attname AS Campo
FROM pg_class a 
JOIN pg_attribute b ON  b.attrelid = a.relfilenode
WHERE  a.relname = 'tab_teste' AND b.attname = 'co_coluna';___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Row level security

2011-11-16 Por tôpico Daniel Cristian Cruz
Em 16 de novembro de 2011 09:38, Paulo Vitor Bettini de Albuqerque
Lima paulovitor...@gmail.com escreveu:
 Caros senhores, Vocês já implementaram em banco permissões de acesso a 
 nível de linhas da tabela? Estou com um cenário que está me tirando o 
 sono. Estou começando um sistema onde os usuários terão permissão para dados 
 de uma determinada localidade. Ou seja, na tabela de acolhida por exemplo, 
 um determinado usuário possui permissão de escrita, mas só pode escrever nas 
 acolhidas dentro da localidade para a qual ele está cadastrado com nível de 
 escrita. Porém ele pode estar associado a outras localidades, com permissão 
 de leitura apenas. Alguém já fez algo do tipo? Ou sabe de algum termo para 
 eu pesquisar sobre? Estou com bastante dúvidas de como modelar isso. 
 Atenciosamente, Paulo Vitor Bettini de Albuquerque Lima 
 http://about.me/paulolima ___ 
 pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br 
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Paulo, bom dia.

Se os dados que o usuário terá acesso são divididos por regiões e
estas regiões são uma chave estrangeira na sua tabela de acolhida, e
cada usuário seja realmente um usuário diferente do banco, acho que
uma solução boa ser utilizar o particionamento de tabelas do
PostgreSQL. Como cada região está em uma partição diferente, teria
como você montar uma trigger em uma tabela de permissão de região que
adicionasse ou removesse as permissões nas partições corretas.

Caso não seja um usuário do banco de dados, recomendaria criar funções
para inclusão, alteração e seleção de dados, retornando uma estrutura
de registro semelhante à sua tabela acolhida.

Atenciosamente,
-- 
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Problemas com o catálogo do PostgreSQL

2011-11-16 Por tôpico JotaComm
Olá, Rogério

Em 16 de novembro de 2011 09:41, Rogério Grando rogeriogra...@planin.com.br
 escreveu:

   Olá pessoal,
 Estive em umas das palestras do PgBr deste ano  “Estatísticas e
 monitoramento e diagnósticos através do catalogo do PostgreSQL” e expus um
 problema que havia ocorrido na mesma semana referente a catálogo, demorei
 um pouco para postar porque estava tentando simular novamente o problema.
 Informações:
 SO: Ubuntu Server, mas fiz um teste no Win e também tive o problema, acho
 que independe do SO.
 PostgreSQl: 8.3.5 compilado.
 Echema: Public
 Encodig UTF8

 Quando é executado o passo 4, alterando o tipo do campo, a ligação
 b.attrelid = a.relfilenode deixa de ser verdadeira, b.attrelid muda de
 valor. Assim o select passo 5 que é igual ao passo 3 não encontra mais o
 registro.
 Fiz algum teste de renomear a coluna e o mesmo não ocorre, aparentemente
 isso acontece apenas quando altero o tipo de dados. Obs. A mesma situação
 ocorre na versão 9.1.
 Não sei se é forma em que consulto o catálogo que está incorreta, e se
 alguém já passou por esse tipo de problema.
 Agradeço pela habitual cordialidade que sempre tive na lista.

 -- 1º
 CREATE DATABASE rteste
   WITH OWNER = postgres
ENCODING = 'UTF8'
TABLESPACE = pg_default
CONNECTION LIMIT = -1;

 -- 2º
 CREATE TABLE tab_teste
 (
   co_coluna numeric
 )
 WITH (
   OIDS=FALSE
 );
 ALTER TABLE tab_teste OWNER TO postgres;

 -- 3º Encontra tabela e campo
 SELECT a.relname AS Tabela, b.attname AS Campo
 FROM pg_class a
 JOIN pg_attribute b ON  b.attrelid = a.relfilenode
 WHERE  a.relname = 'tab_teste' AND b.attname = 'co_coluna';

 -- 4º Provoca o problema
 ALTER TABLE tab_teste ALTER COLUMN co_coluna TYPE double precision;

 -- 5º Não encontra mais tabela e campo
 SELECT a.relname AS Tabela, b.attname AS Campo
 FROM pg_class a
 JOIN pg_attribute b ON  b.attrelid = a.relfilenode
 WHERE  a.relname = 'tab_teste' AND b.attname = 'co_coluna';


Na verdade sua consulta ao catalogo está incorreta, você deve usar oid de
pg_class que é o identificador da tabela com pg_attribute pelo attrelid.

SELECT a.relname AS Tabela, b.attname AS Campo
FROM pg_class a
JOIN pg_attribute b ON  b.attrelid = a.oid
WHERE  a.relname = 'tab_teste' AND b.attname = 'co_coluna';

Se você executar a consulta vai dar o resultado que você espera. O atributo
relfilenode refere-se ao arquivo físico no sitema de arquivos.


 ___
 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


Re: [pgbr-geral] Apoio Técnico

2011-11-16 Por tôpico JotaComm
Olá, Bruno

Em 16 de novembro de 2011 08:54, Fernando Ike f...@midstorm.org escreveu:



 On 15-11-2011 14:42, Bruno Silva wrote:
  Pra você terem idéia, segue um trecho.
  Para esclarecer suas duvidas sobre o ambiente ... preços estimados do
  Oracle, razoes para não usar o PostGre e tudo o mais que você precise
  saber sobre tecnologia. 
 
  O cara não sabe nem o nome do banco, que dirá usá-lo.
  Detalhe, ainda não teve nem a publicação da licitação.
 [...]

   É um FUD![1] Combater FUD não se vence somente com argumentos
 técnicos ou casos

   Decisões baseadas em FUD revelam a pouca maturidade quando pensa TI
 num empresa/instituição. Para combater deve-se usar um pouco mais do
 que preço, pessoal, culpar empresa, etc.

   Erros se cometem com PostgreSQL, Oracle, etc. O que pode argumentar
 que um problema com uma tecnollogia é um pouco mais do culpar a tecnologia.

   TI funcionar bem, precisa-se que os gestores/donos/etc. tenha a
 ciência que TI é parte operacional da empresa. Quanto mais preparada o
 corpo técnico ou prestador de serviço melhor será o custo operacional
 da empresa. Nessa abordagem pode usar as siglas ITIL, COBIT, governança,
 etc.

   O PostgreSQL tem um custo inicial baixo, manutenção médio e um
 retorno de investimento alto à longo prazo. Os bancos SQL proprietário
 tem um custo inicial alto, manutenção médio para alto e um retorno de
 investimento baixo à longo prazo.

   Certeza que é dificílimo encontrar uma empresa realmente boa
 (tecnicamente e custo satisfatório) por aí.


Apenas uma dúvida. Não existia empresa que estava prestando consultoria de
PostgreSQL para o pessoal da Compesa?




 dois centavos,
 --
 Fernando Ike
 http://midstorm.org/~fike/weblog
 ___
 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


Re: [pgbr-geral] Serviço do postgres não inicia

2011-11-16 Por tôpico rvgugisch
Estou tentando rodar o PG 8.4 (atualizado) no windows. Inicialmente em minha
máquina (Localhost)!

Mas estou recebendo a mesma mensagem acima.

De acordo com as mensagens anteriores, eu iniciei o serviço via linha de
comando e o retorno dele foi:

*pg_ctl -D C:\ARQUIV~1\POSTGR~1\8.4\data start
servidor está iniciando

C:\Arquivos de programas\PostgreSQL\8.4\bin2011-11-16 10:59:01 BRT FATAL: 
não pôde criar arquivo de log pg_log/postgresql-2011-11-16_1059
01.log: Permission denied*

Porém, estou rodando a linha de comando como Administrador no windows e já
verifiquei o usuário e senha que o serviço deve iniciar. O usuário
(./postgres) e senha estão corretos.

O mais estranho é que sexta-feira (ultimo dia util aqui) eu rodei o serviço
e criei os bancos e inseri registros normalmente.

Alguém teria mais alguma dica para fazer rodar o serviço?

--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Servico-do-postgres-nao-inicia-tp2027139p4997809.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.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] Serviço do postgres não inicia

2011-11-16 Por tôpico Euler Taveira de Oliveira
On 16-11-2011 11:06, rvgugisch wrote:
 Alguém teria mais alguma dica para fazer rodar o
 serviço?
 
Dar permissão no diretório pg_log ao usuário postgres?


-- 
   Euler Taveira de Oliveira - Timbira   http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] neofito em postgis solicita ajuda para começar os trabalhos

2011-11-16 Por tôpico Angelo Augusto Frozza (IFC)
Olá Antonio,

No campo da modelagem de BD Geo, o BrModelo não é a melhor pedida, pois ele é 
focado em banco de dados relacionais apenas (tem seus méritos como software 
acadêmico ao implementar a notação adotada no livro do Prof. Heuser).

Para BD Geo é necessário utilizar um modelo próprio. Eu, por exemplo, tenho 
adotado o OMT-G (mais ifnormações em 
http://homepages.dcc.ufmg.br/~clodoveu/DocuWiki/doku.php?id=omtg).

Ainda não temos uma boa ferramenta para modelagem em OMT-G (espero ano que vem 
conseguir disponibilizar uma através de um projeto que estou orietando).

Mas você pode começar com o StarUML (p/ Windows - 
http://staruml.sourceforge.net/en/download.php) e usar a extensão criada pelo 
Humberto Pinheiro da UFMG 
(http://sourceforge.net/projects/omt-gextensionf/files/ ou 
http://www.dcc.ufmg.br/~clodoveu/files/OMT-G/setup.exe).

Também tem um Stencil do Visio que o pessoal que desenvolveu o OMT-G 
disponibiliza (http://www.dcc.ufmg.br/~clodoveu/files/OMT-G/OMT-G_portugues.zip)

Tenho interesse nessa área, se quiser vamos avançando nessa conversa.

{}s,

---
A Caverna do Mestre
http://acavernadomestre.blogspot.com/
Prof. Angelo Augusto Frozza, M.Sc.
fro...@ifc-camboriu.edu.br
@TilFrozza
Curso Técnico em Informática
Bacharelado em Sistemas de Informação
Instituto Federal Catarinense - Campus Camboriu
Fone:  (47) 2104 0804 / (49) 9918 0844 
http://www.ifc-camboriu.edu.br/frozza
- Original Message - 
From: antonio borba 
To: Comunidade PostgreSQL Brasileira 
Sent: Saturday, November 12, 2011 12:20 AM
Subject: Re: [pgbr-geral]neofito em postgis solicita ajuda para começar os 
trabalhos


Bom, como disse sou neófito nesse terreno, chaves naturais?, não suporta 
unicidade?, vou ficando com vcs para aprender. Quanto a natureza do trabalho, é 
o seguinte, trabalho com geoprocessamento a um bom tempo, mas sempre usuário de 
ferramentas para georreferenciamento, análise de imagens ... essas coisas. 
estou querendo adentrar a área de modelagem e implementação de sistema para 
gerenciamento de bases de dados geográficas no intuito de realizar a gestão de 
políticas voltadas para agricultura familiar, com os enfoques socioeconômicos e 
ambiental utilizando Postgresql+postgis+gvSIG, de forma a permitir a 
qualificação do gerenciamento da informação, do planejamento e tomada de 
decisão. Mas voltando pra terra do binário,estou agora buscando instalar o 
Postgresql+postgis no ubuntu, em casa, para poder brincar, inicialmente, com 
modelagem usando brmodelo, se não me engano é o nome do programa, e entender, 
estudar o postgre etc... Esse é o desafio e estou contando com a comunidade.

Antonio

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


[pgbr-geral] Problemas com o catálogo do PostgreSQL

2011-11-16 Por tôpico Rogério Grando
Ola JotaComm,

Na mosca, muito obrigado fico te devendo uma cerveja.
Obrigado.



 SELECT a.relname AS Tabela, b.attname AS Campo
 FROM pg_class a
 JOIN pg_attribute b ON  b.attrelid = a.relfilenode
 WHERE  a.relname = 'tab_teste' AND b.attname = 'co_coluna';

Na verdade sua consulta ao catalogo está incorreta, você deve usar oid de
pg_class que é o identificador da tabela com pg_attribute pelo attrelid.

SELECT a.relname AS Tabela, b.attname AS Campo
FROM pg_class a
JOIN pg_attribute b ON  b.attrelid = a.oid
WHERE  a.relname = 'tab_teste' AND b.attname = 'co_coluna';

Se você executar a consulta vai dar o resultado que você espera. O atributo
relfilenode refere-se ao arquivo físico no sitema de arquivos.

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


[pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Marllos
Boa tarde a todos.
Não quero entrar naquela velha discussão: quem é melhor? Mas eu quero
entender.
Tenho um banco de dados Firebird, com 54 tabelas com tamanho total de 30
MB. Migrei esse banco todo para o PostgreSQL 8.4.9. No PostgreSQL o tamanho
do banco ficou em torno dos 30 MB também. Só que o script de criação do
banco, que cria tudo: tabelas, índices, trigger, etc, quando executado para
o Firbird, gasta 133 segundos (2 min), enquanto que no PostgreSQL, com uma
máquina muito superior, gasta 4003055 ms = 66 min. Por que existe toda essa
diferença? O Postgresql levou um tempo 30 vezes maior! O que pode estar
errado? Alguma sugestão?

Obrigado.

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


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Flávio Alves Granato
Em 16 de novembro de 2011 14:43, Marllos marl...@emater.mg.gov.brescreveu:

 Boa tarde a todos.
 Não quero entrar naquela velha discussão: quem é melhor? Mas eu quero
 entender.
 Tenho um banco de dados Firebird, com 54 tabelas com tamanho total de 30
 MB. Migrei esse banco todo para o PostgreSQL 8.4.9. No PostgreSQL o tamanho
 do banco ficou em torno dos 30 MB também. Só que o script de criação do
 banco, que cria tudo: tabelas, índices, trigger, etc, quando executado para
 o Firbird, gasta 133 segundos (2 min), enquanto que no PostgreSQL, com uma
 máquina muito superior, gasta 4003055 ms = 66 min. Por que existe toda essa
 diferença? O Postgresql levou um tempo 30 vezes maior! O que pode estar
 errado? Alguma sugestão?


Acho que há um erro de interpretação. Se ele gastou 4003055 ms então ele
gastou este valor em milisegundos e não em segundos. Não?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Daniel Cristian Cruz
Marllos,

A primeira coisa, na carga por SQL deve ser verificado se os dados
estão dentro de transações (você pode adicionar START TRANSACTION;
antes do primeiro INSERT e COMMIT; depois do último INSERT de cada
tabela).

A segunda coisa a ser verificada é se a configuração está adequada
para o servidor novo. O arquivo de configuração pode estar padrão, e
isso pode limitar um pouco o desempenho.

A terceira coisa a verificar é a versão. Por quê a versão antiga? Não
é o caso, mas nas versões 9.0 em diante, uma carga de um dump através
do comando pg_restore do PostgreSQL, pode ter a opção -j, que indica o
número de tarefas paralelas de restore, que pode usar o processamento
ocioso de sistemas com vários processadores.

Atenciosamente,

Em 16 de novembro de 2011 14:43, Marllos marl...@emater.mg.gov.br escreveu:
 Boa tarde a todos.
 Não quero entrar naquela velha discussão: quem é melhor? Mas eu quero
 entender.
 Tenho um banco de dados Firebird, com 54 tabelas com tamanho total de 30 MB.
 Migrei esse banco todo para o PostgreSQL 8.4.9. No PostgreSQL o tamanho do
 banco ficou em torno dos 30 MB também. Só que o script de criação do banco,
 que cria tudo: tabelas, índices, trigger, etc, quando executado para o
 Firbird, gasta 133 segundos (2 min), enquanto que no PostgreSQL, com uma
 máquina muito superior, gasta 4003055 ms = 66 min. Por que existe toda essa
 diferença? O Postgresql levou um tempo 30 vezes maior! O que pode estar
 errado? Alguma sugestão?

 Obrigado.

 Marllos.

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





-- 
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] View com DB-Link

2011-11-16 Por tôpico Vinicius Santos
Boa tarde pessoal,

Estou com uma dúvida com uma funcionalidade que estou precisando muito.

Tenho uma view +/- assim:

CREATE OR REPLACE VIEW consultar_sao_paulo AS
  SELECT produto, estoque FROM dblink('dbname=sao_paulo', 'SELECT produto,
estoque FROM estoque' )
AS tabela( produto INTEGER, estoque NUMERIC ).

Até aí tudo bem, então chamo esta view assim: SELECT * FROM
consultar_sao_paulo WHERE produto = 31587.

O grande problema é que a cláuse WHERE não é passada para o DB-LINK, então
primeiro ele faz a seleção completa da tabela estoque no banco sao_paulo, e
depois o filtro.

Não faço a menor idéia de como contornar isto, e isto é funcionalidade
crucial para nossa aplicação hoje.

Se realmente não há ainda uma maneira de resolver, será que seria difícil
um patch para isto ? Alguém conhece as entranhas do fonte do DB-LINK, e
sabe me dizer se vale a pena correr atrás de um patch ?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Imagem JPEG 9.1

2011-11-16 Por tôpico Leandro Monqueiro Leme
Qual é o tipo pra colocar jpeg no 9.1 ? no 8.4 era bytea, continua ?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Imagem JPEG 9.1

2011-11-16 Por tôpico Fabiano Abreu
Creio que sim, segue o mesmo padrão..

_ _
Fabiano Abreu
Papo Sql http://paposql.blogspot.com - Um blog com tutoriais, dicas e
truques sobre SQL

2011/11/16 Leandro Monqueiro Leme lmonque...@uol.com.br

 Qual é o tipo pra colocar jpeg no 9.1 ? no 8.4 era bytea, continua ?
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente
_ _
*Fabiano Abreu*
*Papo Sql http://paposql.blogspot.com - Um blog com tutoriais, dicas e
truques sobre Sql
*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] View com DB-Link

2011-11-16 Por tôpico Claudio Oliveira

Olá,
Pela view realmente não vai funcionar.
Vc terá que fazer uma função
create or replace function consulta_estoque(in pwhere text, out Código 
Produto integer, out Estoque Atual numeric) return setof record as $$declare 
r record; comando text;begin comando := 'SELECT produto, estoque FROM estoque ' 
|| ' where' || pwhere; for r in SELECT produto, estoque FROM 
dblink('dbname=sao_paulo', comando)  AS tabela( produto INTEGER, estoque 
NUMERIC )   loop   Código Produto := r.produto;Estoque Atual := 
r.estoque;   return next;  end loop; return;end;$$ language plpgsql;

Vlw.

Claudio Oliveira 
http://www.msisolucoes.com.br

Date: Wed, 16 Nov 2011 15:06:30 -0200
From: vinicius.santos.li...@gmail.com
To: pgbr-geral@listas.postgresql.org.br
Subject: [pgbr-geral] View com DB-Link

Boa tarde pessoal,
 
Estou com uma dúvida com uma funcionalidade que estou precisando muito.
 
Tenho uma view +/- assim:
 
CREATE OR REPLACE VIEW consultar_sao_paulo AS
  SELECT produto, estoque FROM dblink('dbname=sao_paulo', 'SELECT produto, 
estoque FROM estoque' )
AS tabela( produto INTEGER, estoque NUMERIC ).
 
Até aí tudo bem, então chamo esta view assim: SELECT * FROM consultar_sao_paulo 
WHERE produto = 31587.
 
O grande problema é que a cláuse WHERE não é passada para o DB-LINK, então 
primeiro ele faz a seleção completa da tabela estoque no banco sao_paulo, e 
depois o filtro.
 
Não faço a menor idéia de como contornar isto, e isto é funcionalidade crucial 
para nossa aplicação hoje.
 
Se realmente não há ainda uma maneira de resolver, será que seria difícil um 
patch para isto ? Alguém conhece as entranhas do fonte do DB-LINK, e sabe me 
dizer se vale a pena correr atrás de um patch ?

___
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] Imagem JPEG 9.1

2011-11-16 Por tôpico Daniel Cristian Cruz
Acredito que você esteja tendo problemas com a sintaxe do escape.

A opção standard_conforming_strings da configuração pode resolver o
problema de imediato, mas é melhor você tentar ajustar a aplicação
para adicionar o  E'seu arquivo bytea cheio de \ \ \ \ \'  antes dos
conteúdos bytea.

Para testes acho que vale alterar a opção.

2011/11/16 Leandro Monqueiro Leme lmonque...@uol.com.br:
 Qual é o tipo pra colocar jpeg no 9.1 ? no 8.4 era bytea, continua ?
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral





-- 
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] View com DB-Link

2011-11-16 Por tôpico Vinicius Santos
Em 16 de novembro de 2011 15:29, Claudio Oliveira
claudio...@hotmail.comescreveu:

  Olá,

 Pela view realmente não vai funcionar.

 Vc terá que fazer uma função


E ai Claudião !! Tudo blz ???

O problema é que não podemos utilizar função. Estamos mexendo na tela de
Produtos por Localização.

Não há como mudar a aplicação, queremos que fique transparente.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Imagem JPEG 9.1

2011-11-16 Por tôpico Leandro Monqueiro Leme
uso delphi, e no postgres 7.3, 8.1, 8.4, nao apresentavam erro. instalei o 9.1 da o seguinte erro :JPEG error #53 ao ler a imagem, e quando tento gravar, ele nao grava 

Em 16/11/2011 15:27, Fabiano Abreu  fabianoabreual...@gmail.com  escreveu:Creio que sim, segue o mesmo padrão..

_ _
Fabiano Abreu
Papo Sql - Um blog com tutoriais, dicas e truques sobre SQL
2011/11/16 Leandro Monqueiro Leme lmonque...@uol.com.br
Qual é o tipo pra colocar jpeg no 9.1 ? no 8.4 era bytea, continua ? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 



-- Atenciosamente_ _ Fabiano AbreuPapo Sql - Um blog com tutoriais, dicas e truques sobre Sql 

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


Re: [pgbr-geral] Imagem JPEG 9.1

2011-11-16 Por tôpico Bruno Silva
 uso delphi, e no postgres 7.3, 8.1, 8.4, nao apresentavam erro. instalei o
 9.1 da o seguinte erro :

 JPEG error #53 ao ler a imagem, e quando tento gravar, ele nao grava

Você já verificou o log do postgres? O que aparece?
Bruno E. A. Silva.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Marllos
Eu vou instalar uma versão mais nova, quando eu fiz o apt-get ele caiu
automaticamente nessa versao.
Pus um start transaction o inicio e um commit no final geral, isso só já
resolveria? Por que parece que vai gastar o mesmo tempo...

Sobre as configurações do servidor, ainda náo aprendi sobre elas. estou
no começando agora. O primeiro exercicio que me propus foi converter uma
base antiga em postgresql. Isto para aprender a sintaxe e o plgpsql. E toda
a minha fonte de consulta é o manual oficial e esta lista.

Em 16 de novembro de 2011 14:53, Daniel Cristian Cruz 
danielcrist...@gmail.com escreveu:

 Marllos,

 A primeira coisa, na carga por SQL deve ser verificado se os dados
 estão dentro de transações (você pode adicionar START TRANSACTION;
 antes do primeiro INSERT e COMMIT; depois do último INSERT de cada
 tabela).

 A segunda coisa a ser verificada é se a configuração está adequada
 para o servidor novo. O arquivo de configuração pode estar padrão, e
 isso pode limitar um pouco o desempenho.

 A terceira coisa a verificar é a versão. Por quê a versão antiga? Não
 é o caso, mas nas versões 9.0 em diante, uma carga de um dump através
 do comando pg_restore do PostgreSQL, pode ter a opção -j, que indica o
 número de tarefas paralelas de restore, que pode usar o processamento
 ocioso de sistemas com vários processadores.

 Atenciosamente,

 Em 16 de novembro de 2011 14:43, Marllos marl...@emater.mg.gov.br
 escreveu:
  Boa tarde a todos.
  Não quero entrar naquela velha discussão: quem é melhor? Mas eu quero
  entender.
  Tenho um banco de dados Firebird, com 54 tabelas com tamanho total de 30
 MB.
  Migrei esse banco todo para o PostgreSQL 8.4.9. No PostgreSQL o tamanho
 do
  banco ficou em torno dos 30 MB também. Só que o script de criação do
 banco,
  que cria tudo: tabelas, índices, trigger, etc, quando executado para o
  Firbird, gasta 133 segundos (2 min), enquanto que no PostgreSQL, com uma
  máquina muito superior, gasta 4003055 ms = 66 min. Por que existe toda
 essa
  diferença? O Postgresql levou um tempo 30 vezes maior! O que pode estar
  errado? Alguma sugestão?
 
  Obrigado.
 
  Marllos.
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 



 --
 Daniel Cristian Cruz
 クルズ クリスチアン ダニエル
 ___
 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] View com DB-Link

2011-11-16 Por tôpico Vinicius Santos

 não é melhor replicar esta tabela utilizando o bucardo ?

 vc terá uma melhor performance.


Não estamos utilizando replicação. Por DB-LINK as coisas ficariam mais
simples, mas se não tiver jeito após todos os neurônios tiverem pedido
arrego, vamos ter que utilizar replicação sim.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] View com DB-Link

2011-11-16 Por tôpico Vinicius Santos
Pessoal, após pensar um pouco, consegui resolver o problema.

Com este select:

CREATE OR REPLACE VIEW consulta_atual AS
SELECT
substring( current_query FROM position( 'where' IN current_query ) FOR
LENGTH( current_query ) ) AS clausula
FROM
pg_stat_activity
WHERE
procpid = pg_backend_pid();

Este select me traz a clausula WHERE atual. Então posso concatenar na
string que é passada ao DB-LINK.

Meio gambiarristico, mas resolveu o problema. Acredito que o DB-LINK
poderia ler a cláusula WHERE antes de passar a string para o outro banco em
casos como este, mas isto é outra história.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Bruno Silva
 Sobre as configurações do servidor, ainda náo aprendi sobre elas. estou
 no começando agora. O primeiro exercicio que me propus foi converter uma
 base antiga em postgresql. Isto para aprender a sintaxe e o plgpsql. E toda
 a minha fonte de consulta é o manual oficial e esta lista.

Dá uma olhada nos logs do Postgres, geralmente ele informa o que pode
estar dando problemas.

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


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Marllos
Tentei o script com o start transaction na primeira linha e um commit na
útima. O script demorou 3995947 ms que dá 66 min novamente. Ainda teve uma
msg de erro no últimos inserts informando que a transação atual foi
interrompida.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Imagem JPEG 9.1

2011-11-16 Por tôpico Leandro Monqueiro Leme
Desculpe, não entendi essa parte : adicionar o " E'seu arquivo bytea cheio de \ \ \ \ \' "Grato

Em 16/11/2011 15:30, Daniel Cristian Cruz  danielcrist...@gmail.com  escreveu:Acredito que você esteja tendo problemas com a sintaxe do escape.A opção standard_conforming_strings da configuração pode resolver oproblema de imediato, mas é melhor você tentar ajustar a aplicaçãopara adicionar o " E'seu arquivo bytea cheio de \ \ \ \ \' " antes dosconteúdos bytea.Para testes acho que vale alterar a opção.2011/11/16 Leandro Monqueiro Leme : Qual é o tipo pra colocar jpeg no 9.1 ? no 8.4 era bytea, continua ? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral-- Daniel Cristian Cruzクルズ クリスチアン ダニエル___
 pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://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] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Bruno Silva
 Podem estar faltando índices em chaves estrangeiras também...

Ou pode estar criando os indices antes da inserção.

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


Re: [pgbr-geral] Imagem JPEG 9.1

2011-11-16 Por tôpico Daniel Cristian Cruz
Em 16 de novembro de 2011 17:04, Leandro Monqueiro Leme
lmonque...@uol.com.br escreveu:
 Desculpe, não entendi essa parte :

 adicionar o  E'seu arquivo bytea cheio de \ \ \ \ \' 

 Grato

A partir da versão 9.1 é obrigatório o uso da letra E antes de strings
com escape, o que acho ser o caso do bytea da imagem. Se não usar, o
banco trata os \ como caracteres literais.

postgres=# SELECT '\x20A';
 ?column?
--
 \x20A
(1 row)

postgres=# SELECT E'\x20A';
 ?column?
--
  A
(1 row)

Note que a primeira retorna o texto literal e a segunda converte o
\x20 para espaço.


-- 
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Marllos
É o seguinte: primeiro eu crio o banco vazio, então rodo o script no
PgAdminIII que:
1) cria os sequences
2) cria as tabelas
3) crias as views
4) insere os dados
5) cria as constrainsts,
6) cria as functions e triggers

O banco é criado normalmente. Inclusive eu consigo fazer bacup e restore do
banco. O problema é que o firebird faz isso em 2 min e o Postgresql está
fazendo em 66 min.

Estou fazendo o processo novamente e vou verificar o log para ver se tem
alguma dica nele, então eu posto.


Obrigado pelas ajudas


Marllos.

Em 16 de novembro de 2011 17:01, Daniel Cristian Cruz 
danielcrist...@gmail.com creveu:

 Em 16 de novembro de 2011 16:53, Marllos 
 marllos@emater.marl...@emater.mg.gov.br
 Tentei o script com o start transaction na primeira linha e um commit na
  útima. O script demorou 3995947 ms que dá 66 min novamente. Ainda teve
 uma
  msg de erro no últimos inserts informando que a transação atual foi
  interrompida.

 Provavelmente devido a algum comando SQL não compatível. Conforme o
 Bruno falou, confira no log do banco os erros que ocorreram.

 Podem estar faltando índices em chaves estrangeiras também...
 --
 Daniel Cristian Cruz
 クルズ クリスチアン ダニエル
 ___
 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] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Leandro DUTRA, Guimarães Faria Corcete
Le 2011-16-11 17h19, Marllos a écrit :
 É o seguinte: primeiro eu crio o banco vazio, então rodo o script no
 PgAdminIII que:
 1) cria os sequences
 2) cria as tabelas
 3) crias as views
 4) insere os dados

E quando são criados os índices?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Bruno Silva
 O banco é criado normalmente. Inclusive eu consigo fazer bacup e restore do
 banco. O problema é que o firebird faz isso em 2 min e o Postgresql está
 fazendo em 66 min.

O hardware é o mesmo? Qual o SO?


 É o seguinte: primeiro eu crio o banco vazio, então rodo o script no
 PgAdminIII que:
 1) cria os sequences
 2) cria as tabelas
 3) crias as views
 4) insere os dados
 5) cria as constrainsts,
 6) cria as functions e triggers

E os indices, são criados em que momento?

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


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Marllos
Em 16 de novembro de 2011 17:32, Marllos marl...@emater.mg.gov.brescreveu:

 Sim, depois de inserir os dados, eu crio os indices e as outras
 constraints
 Mas, o que está demorando 66 min é a estapa de inserir os dados, nesse
 momente não existe indice

 1) cria os sequences -- rapido
 2) cria as tabelas -- rapido
 3) crias as views -- rapido
 4) insere os dados -- 66 min
 5) cria as constrainsts, -- rapidor
 6) cria as functions e triggers -- rapido

 No firebird, eu sigo essa mesma ordem e tudo termina com menos de 2 min

 Em 16 de novembro de 2011 17:23, Leandro DUTRA, Guimarães Faria Corcete
 l...@dutras.org escreveu:

 Le 2011-16-11 17h19, Marllos a écrit :

  É o seguinte: primeiro eu crio o banco vazio, então rodo o script no
 PgAdminIII que:
 1) cria os sequences
 2) cria as tabelas
 3) crias as views
 4) insere os dados


 E quando são criados os índices?



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


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Marllos
Eu rodo o firebird no computador hp, processador amd dual core 64 bits;
2,59 GHZ 1,75 MB ram com o xp
O Postgresql está num Dell 64 bits 4 nucleos 2,5 GHz; 32 MB de ram com o
Ubuntu 10.10


Em 16 de novembro de 2011 17:25, Bruno Silva bemanuel...@gmail.comescreveu:

  O banco é criado normalmente. Inclusive eu consigo fazer bacup e restore
 do
  banco. O problema é que o firebird faz isso em 2 min e o Postgresql está
  fazendo em 66 min.

 O hardware é o mesmo? Qual o SO?


  É o seguinte: primeiro eu crio o banco vazio, então rodo o script no
  PgAdminIII que:
  1) cria os sequences
  2) cria as tabelas
  3) crias as views
  4) insere os dados
  5) cria as constrainsts,
  6) cria as functions e triggers

 E os indices, são criados em que momento?

 Bruno E. A. Silva.
 ___
 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] View com DB-Link

2011-11-16 Por tôpico Osvaldo Kussama
Em 16/11/11, Vinicius Santosvinicius.santos.li...@gmail.com escreveu:
 Pessoal, após pensar um pouco, consegui resolver o problema.

 Com este select:

 CREATE OR REPLACE VIEW consulta_atual AS
 SELECT
 substring( current_query FROM position( 'where' IN current_query ) FOR
 LENGTH( current_query ) ) AS clausula
 FROM
 pg_stat_activity
 WHERE
 procpid = pg_backend_pid();

 Este select me traz a clausula WHERE atual. Então posso concatenar na
 string que é passada ao DB-LINK.

 Meio gambiarristico, mas resolveu o problema. Acredito que o DB-LINK
 poderia ler a cláusula WHERE antes de passar a string para o outro banco em
 casos como este, mas isto é outra história.



Não alcancei o que você espera do dblink.
Você espera que a função leve em consideração informações fora do
escopo dos parâmetros que lhe são fornecidos?

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] Imagem JPEG 9.1

2011-11-16 Por tôpico Osvaldo Kussama
2011/11/16, Leandro Monqueiro Leme lmonque...@uol.com.br:
 Qual é o tipo pra colocar jpeg no 9.1 ? no 8.4 era bytea, continua ?


A partir da versão 9.0 foi introduzida a seguinte alteração:
The bytea type supports two external formats for input and output:
PostgreSQL's historical escape format, and hex format. Both of
these are always accepted on input. The output format depends on the
configuration parameter bytea_output; the default is hex. (Note that
the hex format was introduced in PostgreSQL 9.0; earlier versions and
some tools don't understand it.) 
(http://www.postgresql.org/docs/current/interactive/datatype-binary.html)

Verifique se não é esta modificação que está acarretando problemas em
sua aplicação.

Pode ser que mudando o parâmetro bytea_output (enum) do
postgresql.conf (de hex para escape) ele passe a tratar os campos
bytea da maneira que sua aplicação espera.

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] Imagem JPEG 9.1

2011-11-16 Por tôpico Daniel Cristian Cruz
Nossa, se esse fosse um fórum, eu marcava como spam meus posts
anteriores e positivava a tua resposta.

Eu não sabia da diferença de tratamento entre texto e bytea.
Aprendendo um pouco a cada dia.

Desculpem-me pela confusão anterior.

Em 16 de novembro de 2011 18:25, Osvaldo Kussama
osvaldo.kuss...@gmail.com escreveu:
 2011/11/16, Leandro Monqueiro Leme lmonque...@uol.com.br:
 Qual é o tipo pra colocar jpeg no 9.1 ? no 8.4 era bytea, continua ?


 A partir da versão 9.0 foi introduzida a seguinte alteração:
 The bytea type supports two external formats for input and output:
 PostgreSQL's historical escape format, and hex format. Both of
 these are always accepted on input. The output format depends on the
 configuration parameter bytea_output; the default is hex. (Note that
 the hex format was introduced in PostgreSQL 9.0; earlier versions and
 some tools don't understand it.) 
 (http://www.postgresql.org/docs/current/interactive/datatype-binary.html)

 Verifique se não é esta modificação que está acarretando problemas em
 sua aplicação.

 Pode ser que mudando o parâmetro bytea_output (enum) do
 postgresql.conf (de hex para escape) ele passe a tratar os campos
 bytea da maneira que sua aplicação espera.

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




-- 
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Marcal Hokama


 Date: Wed, 16 Nov 2011 17:38:30 -0200 
 From: marl...@emater.mg.gov.br 
 To: pgbr-geral@listas.postgresql.org.br 
 Subject: Re: [pgbr-geral] Script está demorando muito no PostgreSQL 
  
 Eu rodo o firebird no computador hp, processador amd dual core 64 bits;  
 2,59 GHZ 1,75 MB ram com o xp 
 O Postgresql está num Dell 64 bits 4 nucleos 2,5 GHz; 32 MB de ram com  
 o Ubuntu 10.10 
  
  

Marllos, sugiro a leitura desta parte do manual do PostgreSQL, que trata 
justamente sobre grande quantidade de INSERTS para popular um banco de dados:

http://www.postgresql.org/docs/8.4/static/populate.html


ainda, segue abaixo o link para uma página mostrando como montar os INSERTS 
para serem mais rápidos, caso não consiga usar o comando COPY:

http://kaiv.wordpress.com/2007/07/19/faster-insert-for-multiple-rows/


Marçal de Lima Hokama
--



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


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Bruno Silva
 Eu rodo o firebird no computador hp, processador amd dual core 64 bits; 2,59
 GHZ 1,75 MB ram com o xp
 O Postgresql está num Dell 64 bits 4 nucleos 2,5 GHz; 32 MB de ram com o
 Ubuntu 10.10

Com certeza alguns ajustes iam ajudar muito nessa importação. Como
estás iniciando, faz uns testes com o pgtune[1]

[1]http://pgfoundry.org/projects/pgtune/

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


Re: [pgbr-geral] View com DB-Link

2011-11-16 Por tôpico Flavio Henrique Araque Gurgel
 Não alcancei o que você espera do dblink.
 Você espera que a função leve em consideração informações fora do
 escopo dos parâmetros que lhe são fornecidos?

Além da dica do nosso caro Osvaldo, fica outra: PostgreSQL 9.1 com
FDW, esse problema do DB-Link vai embora, a consulta será um simples
SELECT direto na tabela estrangeira.

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


Re: [pgbr-geral] Imagem JPEG 9.1

2011-11-16 Por tôpico Flavio Henrique Araque Gurgel
 Nossa, se esse fosse um fórum, eu marcava como spam meus posts
 anteriores e positivava a tua resposta.

 Eu não sabia da diferença de tratamento entre texto e bytea.
 Aprendendo um pouco a cada dia.

Fica a dica pra todo mundo:
Quem está migrando aplicações de 8.4 para 9.0 ou superiores, as
principais diferenças para as aplicações são:
9.0+ bytea_output
9.1 standard_conforming_strings

Ajustando as configurações acima (pra todo o cluster, para um banco de
dados, uma role ou direto numa sessão) resolve 99% das
incompatibilidades de aplicações legadas com as versões mais novas do
PostgreSQL.

Dica de quem migrou mais de 10 sistemas pré-8.4 para 9.0+

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


Re: [pgbr-geral] Script está demorando muito no PostgreSQL

2011-11-16 Por tôpico Danilo Silva
Marlos,

Diga quais são os valores dos parâmetros shared_buffers e
checkpoint_segments.

att.

Danilo

Em 17 de novembro de 2011 00:49, Bruno Silva bemanuel...@gmail.comescreveu:

  Eu rodo o firebird no computador hp, processador amd dual core 64 bits;
 2,59
  GHZ 1,75 MB ram com o xp
  O Postgresql está num Dell 64 bits 4 nucleos 2,5 GHz; 32 MB de ram com o
  Ubuntu 10.10

 Com certeza alguns ajustes iam ajudar muito nessa importação. Como
 estás iniciando, faz uns testes com o pgtune[1]

 [1]http://pgfoundry.org/projects/pgtune/

 Bruno E. A. Silva.
 ___
 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