Re: [pgbr-geral] duvida com log

[Flavio Henrique Araque Gurgel]

> Bom dia Pessoal,
> estou utilizando a versao do Postgres 9.1 com o pgbouncer 9.2 con CentOS
> 6.3.
> ocorre que de uns dias para cá está ficando umas conexões "fantasmas",
> que acredito seja algo alterado em nosso sistema.
> no log do postgresql existe essas informações abaixo, alguem poderia me
> ajudar com mais detalhes?
> 
> 
> 2016-04-25 11:43:44 BRT [327]: [19-1]
> user=motor,db=motor,app=[unknown],client=127.0.0.1 COMMIT 25P01 WARNING:
>  25P01: there is no transaction in progress
> 2016-04-25 11:43:44 BRT [327]: [20-1]
> user=motor,db=motor,app=[unknown],client=127.0.0.1 COMMIT 25P01
> LOCATION:  EndTransactionBlock, xact.c:3276

Neste trecho de log acima, sua aplicação fez um COMMIT sem ter feito um
BEGIN.
Pode ser sua aplicação ou outra camada que isole sua aplicação do banco
de daos, então, a investigação pode ser em vários níveis.

[]s
Flavio Gurgel

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

[pgbr-geral] duvida com log

[Douglas Fabiano Specht]

Bom dia Pessoal,
estou utilizando a versao do Postgres 9.1 com o pgbouncer 9.2 con CentOS
6.3.
ocorre que de uns dias para cá está ficando umas conexões "fantasmas", que
acredito seja algo alterado em nosso sistema.
no log do postgresql existe essas informações abaixo, alguem poderia me
ajudar com mais detalhes?


2016-04-25 11:43:44 BRT [327]: [19-1]
user=motor,db=motor,app=[unknown],client=127.0.0.1 COMMIT 25P01 WARNING:
 25P01: there is no transaction in progress
2016-04-25 11:43:44 BRT [327]: [20-1]
user=motor,db=motor,app=[unknown],client=127.0.0.1 COMMIT 25P01 LOCATION:
 EndTransactionBlock, xact.c:3276


-- 

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

[pgbr-geral] Duvida

[Reijanio Nunes Ribeiro]

No firebird qdo quero usar parametros em sintaxe sql uso dessa forma

Select * from tabela where camoo = :pcampo

Compo fica ria essa sintaxe no postgresql

Desde ja grato pela atençã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] Duvida

[Ivo Sestren Junior]

Se você está falando usando no delphi. O parâmetro continua igual.

Em sáb, 16 de jan de 2016 06:44, Reijanio Nunes Ribeiro 
escreveu:

> No firebird qdo quero usar parametros em sintaxe sql uso dessa forma
>
> Select * from tabela where camoo = :pcampo
>
> Compo fica ria essa sintaxe no postgresql
>
> Desde ja grato pela atenção
> ___
> 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] Duvida

[iannsp]

dentro do postgresql,
http://www.postgresql.org/docs/9.2/static/sql-prepare.html


no caso da utilização de prepared statement em implementações cliente a
sintaxe é padrão.

ou o uso de "?" , onde o bind é feito acessando os placeholder "?" como
um array zero based.

ou de ":"+name
onde os placeholder são acessiveis ao bind via ":"+name



On 1/16/16 10:08 AM, Ivo Sestren Junior wrote:
> Se você está falando usando no delphi. O parâmetro continua igual.
> 
> 
> Em sáb, 16 de jan de 2016 06:44, Reijanio Nunes Ribeiro
> > escreveu:
> 
> No firebird qdo quero usar parametros em sintaxe sql uso dessa forma
> 
> Select * from tabela where camoo = :pcampo
> 
> Compo fica ria essa sintaxe no postgresql
> 
> Desde ja grato pela atenção
> 
> ___
> 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

Re: [pgbr-geral] Duvida

[Reijanio Nunes Ribeiro]

no gerenciador tipo ems ou outro qualquer

Em 16 de janeiro de 2016 10:18, iannsp  escreveu:
> dentro do postgresql,
> http://www.postgresql.org/docs/9.2/static/sql-prepare.html
>
>
> no caso da utilização de prepared statement em implementações cliente a
> sintaxe é padrão.
>
> ou o uso de "?" , onde o bind é feito acessando os placeholder "?" como
> um array zero based.
>
> ou de ":"+name
> onde os placeholder são acessiveis ao bind via ":"+name
>
>
>
> On 1/16/16 10:08 AM, Ivo Sestren Junior wrote:
>> Se você está falando usando no delphi. O parâmetro continua igual.
>>
>>
>> Em sáb, 16 de jan de 2016 06:44, Reijanio Nunes Ribeiro
>> > escreveu:
>>
>> No firebird qdo quero usar parametros em sintaxe sql uso dessa forma
>>
>> Select * from tabela where camoo = :pcampo
>>
>> Compo fica ria essa sintaxe no postgresql
>>
>> Desde ja grato pela atenção
>>
>> ___
>> 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



-- 
Reijanio Nunes Ribeiro
Desenvolvedor Delphi/Php
Suporte em TI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] duvida com return as json

[Douglas Fabiano Specht]

Boa noite Pessoal,
vejam se podem me ajudar, tenho um a função no postgresql 9.4 que me
retorna um json, mas esta ocorrendo erro ao executar a mesma, sendo que se
executar somente o select do json, está funcionando, logo acho que é algo
em relação ao retorno da função..

retornando o erro:
ERROR:  query has no destination for result data
HINT:  If you want to discard the results of a SELECT, use PERFORM instead.
CONTEXT:  PL/pgSQL function get_historico_mensagem(integer,character
varying) line 11 at SQL statement



CREATE OR REPLACE FUNCTION public.get_historico_mail(
_idmail integer,
_token character varying)
  RETURNS json AS

  --DECLARE
  _tokencal varchar;

  BEGIN
  _tokencal=CAST(_idmail as VARCHAR);
IF EXISTS (SELECT 1 from maillog where idmail=_idmail) then
IF getmd5(_token,_tokencal) THEN
SELECT row_to_json(r)
FROM
(SELECT array_agg(mp.idmail) idmail, array_agg(mp.telefone) telefone,
array_agg(mp.datahoraenvio) datahoraenvio, array_agg(mp.id) id,
 array_agg(mp.dtregistro) dtregistro, array_agg(mp.datahoraenvio)  dtenvio
  FROM maillog mp where mp.idmail=_idmail
  ) r
   where r IS NOT NULL;
else
RAISE EXCEPTION '%','INVALID TOKEN';
END IF;
else
RAISE EXCEPTION '%','mail não encontrado ('||_idmail||')';
END IF;
  END;
$BODY$
  LANGUAGE plpgsql VOLATILE SECURITY DEFINER


-- 

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

Re: [pgbr-geral] duvida com return as json

[Matheus de Oliveira]

On Mon, May 4, 2015 at 11:06 PM, Douglas Fabiano Specht 
douglasfabi...@gmail.com wrote:



 retornando o erro:
 ERROR:  query has no destination for result data
 HINT:  If you want to discard the results of a SELECT, use PERFORM instead.
 CONTEXT:  PL/pgSQL function get_historico_mensagem(integer,character
 varying) line 11 at SQL statement



 CREATE OR REPLACE FUNCTION public.get_historico_mail(
 ...
 SELECT row_to_json(r)
 ...


O problema é que você executa essa consulta e não usa o retorno desta em
nenhum lugar. Além disso, sua função não faz retorno algum. Se você quiser
retornar o resultado do row_to_json, você deve salvar numa variável (usando
o INTO) e retorná-la, algo como:

DECLARE
ret json;
...
-- Executa a query e salva o resultado em ret:
SELECT row_to_json(r) INTO ret
FROM ... resto do SELECT
-- Retorna a variável ret na função:
RETURN ret;
...

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com return as json

[Douglas Fabiano Specht]

2015-05-06 11:12 GMT-03:00 Matheus de Oliveira matioli.math...@gmail.com:


 On Mon, May 4, 2015 at 11:06 PM, Douglas Fabiano Specht 
 douglasfabi...@gmail.com wrote:



 retornando o erro:
 ERROR:  query has no destination for result data
 HINT:  If you want to discard the results of a SELECT, use PERFORM
 instead.
 CONTEXT:  PL/pgSQL function get_historico_mensagem(integer,character
 varying) line 11 at SQL statement



 CREATE OR REPLACE FUNCTION public.get_historico_mail(
 ...
 SELECT row_to_json(r)
 ...


 O problema é que você executa essa consulta e não usa o retorno desta em
 nenhum lugar. Além disso, sua função não faz retorno algum. Se você quiser
 retornar o resultado do row_to_json, você deve salvar numa variável (usando
 o INTO) e retorná-la, algo como:

 DECLARE
 ret json;
 ...
 -- Executa a query e salva o resultado em ret:
 SELECT row_to_json(r) INTO ret
 FROM ... resto do SELECT
 -- Retorna a variável ret na função:
 RETURN ret;
 ...

 Atenciosamente,
 --
 Matheus de Oliveira
 Analista de Banco de Dados
 Dextra Sistemas - MPS.Br nível F!
 www.dextra.com.br/postgres


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


Obrigado..
resolvido..

-- 

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

[pgbr-geral] duvida com campo que deferia ser FK

[Douglas Fabiano Specht]

Pessoal,
preciso tirar uma duvida com voces.
tenho uma tabela chamada empresa, que seria a identificação de quem fez
determinado cadastro ou operação no sistema.
O campo idempresa é alimentado em 50% de 700 tabelas.
logo eu deveria de criar esse campo como FK nas 350 tabelas? ou crio
somente o campo idempresa (int) para armazenar tal informação?


-- 

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

Re: [pgbr-geral] duvida com campo que deferia ser FK

[Guimarães Faria Corcete DUTRA , Leandro]

2015-03-03 13:48 GMT-03:00 Douglas Fabiano Specht douglasfabi...@gmail.com:
 O campo idempresa é alimentado em 50% de 700 tabelas.
 logo eu deveria de criar esse campo como FK nas 350 tabelas?

Por que não?


 ou crio somente
 o campo idempresa (int) para armazenar tal informação?

O ideal seria uma chave natural, como por exemplo CNPJ.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com trigger

[Matheus de Oliveira]

2015-02-18 12:30 GMT-02:00 Douglas Fabiano Specht douglasfabi...@gmail.com
:

 a trigger esta na tabela tabela movimento, e o delete é nela mesmo.
 se eu colocar no before e dentro de um bloco de transação dar rollback na
 aplicação a trigger será executada?
 exemplo

 begin
 insert na table X
 delete movimento(executa a trigger no before)
 update tabela Y(aqui ocorre um erro e um rollback)


Sim, vai ser executada mas o INSERT feito dentro da função de trigger vai
naturalmente ser desfeito. De qualquer modo isso não tem relação com o fato
de ser AFTER ou BEFORE, o mesmo se aplica à ambos.

Concordo com o Fabrízio, você queria ter criado uma trigger do tipo BEFORE.

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com trigger

[Fabrízio de Royes Mello]

On 18-02-2015 11:44, Douglas Fabiano Specht wrote:
 Bom dia Pessoal
 
 tenho uma trigger after insert or delete, postgres 9.4, que se for feito um
 delete eu preciso dar um insert em uma tabela com um join.
 até ai tudo certo, ocorre que não esta fazendo o insert, pois o select não
 deve estar retornado dados.
 
 if (TG_OP = 'DELETE') then
 insert into dah.wdados(codempresa, tipo, codigo, titular, nro, chave,
 celular, dataoperacao)
 select old.codempresa, 'CO', old.codigo, old.nome, old.acesso, old.chave,
 c.celular, CURRENT_TIMESTAMP
 from cadcliente c
 join movimento h on (c.codigo = h.codigo )
 where (h.chave = old.chave and h.codempresa=old.codempresa) ;
 return old;
   END IF;
 
 alguma dica ou segredo pra poder fazer esse join com where utilizando as
 colunas OLD?
 ou como eu poderia salvar o comando com seus valores? estou usando o
 debbuger do pgadmin, mas os valores dos campos não mostram.
 

Douglas,

Em qual tabela está essa trigger?? Lembre-se que o AFTER já considera a
operação efetivada, ou seja, se a sua query com JOIN precisa das tuplas
excluidas não serão retornadas. Me parece que vc precisa colocar esse
seu INSERT no BEFORE DELETE.

Att,

-- 
   Fabrízio de Royes Mello 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] duvida com trigger

[Douglas Fabiano Specht]

Em 18 de fevereiro de 2015 12:18, Fabrízio de Royes Mello 
fabri...@timbira.com.br escreveu:

 On 18-02-2015 11:44, Douglas Fabiano Specht wrote:
  Bom dia Pessoal
 
  tenho uma trigger after insert or delete, postgres 9.4, que se for feito
 um
  delete eu preciso dar um insert em uma tabela com um join.
  até ai tudo certo, ocorre que não esta fazendo o insert, pois o select
 não
  deve estar retornado dados.
 
  if (TG_OP = 'DELETE') then
  insert into dah.wdados(codempresa, tipo, codigo, titular, nro, chave,
  celular, dataoperacao)
  select old.codempresa, 'CO', old.codigo, old.nome, old.acesso, old.chave,
  c.celular, CURRENT_TIMESTAMP
  from cadcliente c
  join movimento h on (c.codigo = h.codigo )
  where (h.chave = old.chave and h.codempresa=old.codempresa) ;
  return old;
END IF;
 
  alguma dica ou segredo pra poder fazer esse join com where utilizando as
  colunas OLD?
  ou como eu poderia salvar o comando com seus valores? estou usando o
  debbuger do pgadmin, mas os valores dos campos não mostram.
 

 Douglas,

 Em qual tabela está essa trigger?? Lembre-se que o AFTER já considera a
 operação efetivada, ou seja, se a sua query com JOIN precisa das tuplas
 excluidas não serão retornadas. Me parece que vc precisa colocar esse
 seu INSERT no BEFORE DELETE.

 Att,

 --
Fabrízio de Royes Mello 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


Fabrizio,
a trigger esta na tabela tabela movimento, e o delete é nela mesmo.
se eu colocar no before e dentro de um bloco de transação dar rollback na
aplicação a trigger será executada?
exemplo

begin
insert na table X
delete movimento(executa a trigger no before)
update tabela Y(aqui ocorre um erro e um rollback)



-- 

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

[pgbr-geral] duvida com trigger

[Douglas Fabiano Specht]

Bom dia Pessoal

tenho uma trigger after insert or delete, postgres 9.4, que se for feito um
delete eu preciso dar um insert em uma tabela com um join.
até ai tudo certo, ocorre que não esta fazendo o insert, pois o select não
deve estar retornado dados.

if (TG_OP = 'DELETE') then
insert into dah.wdados(codempresa, tipo, codigo, titular, nro, chave,
celular, dataoperacao)
select old.codempresa, 'CO', old.codigo, old.nome, old.acesso, old.chave,
c.celular, CURRENT_TIMESTAMP
from cadcliente c
join movimento h on (c.codigo = h.codigo )
where (h.chave = old.chave and h.codempresa=old.codempresa) ;
return old;
  END IF;

alguma dica ou segredo pra poder fazer esse join com where utilizando as
colunas OLD?
ou como eu poderia salvar o comando com seus valores? estou usando o
debbuger do pgadmin, mas os valores dos campos não mostram.


-- 

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

Re: [pgbr-geral] duvida com trigger

[Fabrízio de Royes Mello]

On 18-02-2015 23:02, Douglas Fabiano Specht wrote:
 obrigado Matheus e Fabrizio,
 neste caso entao de utilizar o before, e der um rollback, ele vai desfazer
 o insert mesmo que seja feito em outra tabela correto?
 

É isso ai meu guri... o PostgreSQL é ACID, então lembre-se do
A=Atomicidade, ou seja, ou faz tudo ou não faz nada... ;-)

E um INSERT/UPDATE/DELETE em uma tabela que tem um gatilho é uma
transação só... blz?

Att,

-- 
   Fabrízio de Royes Mello 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] duvida com trigger

[Douglas Fabiano Specht]

Em 18 de fevereiro de 2015 12:34, Matheus de Oliveira 
matioli.math...@gmail.com escreveu:


 2015-02-18 12:30 GMT-02:00 Douglas Fabiano Specht 
 douglasfabi...@gmail.com:

 a trigger esta na tabela tabela movimento, e o delete é nela mesmo.
 se eu colocar no before e dentro de um bloco de transação dar rollback na
 aplicação a trigger será executada?
 exemplo

 begin
 insert na table X
 delete movimento(executa a trigger no before)
 update tabela Y(aqui ocorre um erro e um rollback)


 Sim, vai ser executada mas o INSERT feito dentro da função de trigger vai
 naturalmente ser desfeito. De qualquer modo isso não tem relação com o fato
 de ser AFTER ou BEFORE, o mesmo se aplica à ambos.

 Concordo com o Fabrízio, você queria ter criado uma trigger do tipo BEFORE.

 Atenciosamente,
 --
 Matheus de Oliveira
 Analista de Banco de Dados
 Dextra Sistemas - MPS.Br nível F!
 www.dextra.com.br/postgres


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


obrigado Matheus e Fabrizio,
neste caso entao de utilizar o before, e der um rollback, ele vai desfazer
o insert mesmo que seja feito em outra tabela correto?


-- 

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

Re: [pgbr-geral] Duvida com Enconding

[Osvaldo Kussama]

Em 10/01/15, Vinicius Santosvinicius.santos.li...@gmail.com escreveu:
 Em 10 de janeiro de 2015 09:34, Vinicius Santos 
 vinicius.santos.li...@gmail.com escreveu:

 Bom dia pessoal,

 Criei um banco de dados herdando de template0 usando a codificação
 WIN1252.

 Tenho um arquivo txt codificado em ANSI, e ao tentar importá-lo com COPY,
 tenho o seguinte:

 ERRO:  sequência de bytes é inválida para codificação UTF8: 0xc74f
 HINT:  Este erro pode acontecer também se a sequência de bytes não
 corresponde a codificação esperado pelo servidor, que é controlada por
 client_encoding.
 CONTEXT:  COPY arquivo, linha 48919

 Minha dúvida é a seguinte: Porque a mensagem diz UTF8?? Meu banco é
 Win1252, não UTF8.

 PostgreSQL 8.4.12 no Windows.


 Apenas pra constar.

 Fiz o mesmo usando encoding SQL_ASCII e funcionou.


Isto significa que não é para fazer nenhuma verificação sobre a
codificação utilizada.
Não deve ser utilizado.
Se você utilizar diferentes clientes com diferentes codificações para
alimentar o banco você terá que saber exatamente qual codificação cada
cliente utilizou para recuperar corretamente os dados do banco.

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] Duvida com Enconding

[Vinicius Santos]

Em 10 de janeiro de 2015 09:34, Vinicius Santos 
vinicius.santos.li...@gmail.com escreveu:

 Bom dia pessoal,

 Criei um banco de dados herdando de template0 usando a codificação WIN1252.

 Tenho um arquivo txt codificado em ANSI, e ao tentar importá-lo com COPY,
 tenho o seguinte:

 ERRO:  sequência de bytes é inválida para codificação UTF8: 0xc74f
 HINT:  Este erro pode acontecer também se a sequência de bytes não
 corresponde a codificação esperado pelo servidor, que é controlada por
 client_encoding.
 CONTEXT:  COPY arquivo, linha 48919

 Minha dúvida é a seguinte: Porque a mensagem diz UTF8?? Meu banco é
 Win1252, não UTF8.

 PostgreSQL 8.4.12 no Windows.


Apenas pra constar.

Fiz o mesmo usando encoding SQL_ASCII e funcionou.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida com Enconding

[Vinicius Santos]

Em 10 de janeiro de 2015 11:38, Osvaldo Kussama osvaldo.kuss...@gmail.com
escreveu:

 Em 10/01/15, Vinicius Santosvinicius.santos.li...@gmail.com escreveu:
  Bom dia pessoal,
 
  Criei um banco de dados herdando de template0 usando a codificação
 WIN1252.
 
  Tenho um arquivo txt codificado em ANSI, e ao tentar importá-lo com COPY,
  tenho o seguinte:
 
  ERRO:  sequência de bytes é inválida para codificação UTF8: 0xc74f
  HINT:  Este erro pode acontecer também se a sequência de bytes não
  corresponde a codificação esperado pelo servidor, que é controlada por
  client_encoding.
  CONTEXT:  COPY arquivo, linha 48919
 
  Minha dúvida é a seguinte: Porque a mensagem diz UTF8?? Meu banco é
  Win1252, não UTF8.
 
  PostgreSQL 8.4.12 no Windows.
 


 Você tem que verificar o que está declarado tanto do lado do cliente
 quanto do lado do servidor e assegurar que os dados estejam
 compatíveis com as declarações.

 SHOW CLIENT_ENCODING;
 SHOW SERVER_ENCODING;



Matou a xarada.
O client_encoding estava UTF8.

Rodei set client_encoding = 'WIN1252' e a importação funcionou.

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

[pgbr-geral] Duvida com Enconding

[Vinicius Santos]

Bom dia pessoal,

Criei um banco de dados herdando de template0 usando a codificação WIN1252.

Tenho um arquivo txt codificado em ANSI, e ao tentar importá-lo com COPY,
tenho o seguinte:

ERRO:  sequência de bytes é inválida para codificação UTF8: 0xc74f
HINT:  Este erro pode acontecer também se a sequência de bytes não
corresponde a codificação esperado pelo servidor, que é controlada por
client_encoding.
CONTEXT:  COPY arquivo, linha 48919

Minha dúvida é a seguinte: Porque a mensagem diz UTF8?? Meu banco é
Win1252, não UTF8.

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

Re: [pgbr-geral] Duvida com Enconding

[Osvaldo Kussama]

Em 10/01/15, Osvaldo Kussamaosvaldo.kuss...@gmail.com escreveu:

Complementando, veja:
http://www.postgresql.org/docs/9.4/static/charset.html

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

Re: [pgbr-geral] Duvida com Enconding

[Osvaldo Kussama]

Em 10/01/15, Vinicius Santosvinicius.santos.li...@gmail.com escreveu:
 Bom dia pessoal,

 Criei um banco de dados herdando de template0 usando a codificação WIN1252.

 Tenho um arquivo txt codificado em ANSI, e ao tentar importá-lo com COPY,
 tenho o seguinte:

 ERRO:  sequência de bytes é inválida para codificação UTF8: 0xc74f
 HINT:  Este erro pode acontecer também se a sequência de bytes não
 corresponde a codificação esperado pelo servidor, que é controlada por
 client_encoding.
 CONTEXT:  COPY arquivo, linha 48919

 Minha dúvida é a seguinte: Porque a mensagem diz UTF8?? Meu banco é
 Win1252, não UTF8.

 PostgreSQL 8.4.12 no Windows.



Você tem que verificar o que está declarado tanto do lado do cliente
quanto do lado do servidor e assegurar que os dados estejam
compatíveis com as declarações.

SHOW CLIENT_ENCODING;
SHOW SERVER_ENCODING;

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] Duvida sobre Replicated Cluster no Postgres 9.3

[Fabio Eckhardt]

Sebastian,

Preciso realizar uma Replicação em Cluster usando dois nodo multistate
(master / slave), mas com Sistema Operacional Ubuntu e não Fedora.

Em poucas precisaria repedir o processo no link abaixo com S.O Ubuntu (e
nao Fedora) :

http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster

Sabes se existe alguma documentação na web pra S.O Ubuntu ?


Em 1 de dezembro de 2014 13:40, Sebastian Webber sebastian...@gmail.com
escreveu:

 2014-12-01 8:48 GMT-02:00 Fabio Eckhardt 
 fabioeckha...@universo.univates.br:

 Sebastian,

 Sou sincero em lhe dizer, não sou muito fã de FEDORA. E atualmente a
 melhor documentação que existe é pra FEDORA.

 Sabes algum material na internet para UBUNTU (e postgres 9.3) para
 realizar uma a Replicação de Cluster com 2 servidores Postgres, isto é  2
 nodo multistate cluster. ???


 Fábio,

 Tu poderias ser mais específico com o que tu precisa fazer? Confesso que
 não entendi o que tu precisas.


 --
 Sebastian Webber
 http://swebber.me




-- 

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

Re: [pgbr-geral] Duvida sobre Replicated Cluster no Postgres 9.3

[Matheus de Oliveira]

2014-12-02 10:02 GMT-02:00 Fabio Eckhardt 
fabioeckha...@universo.univates.br:

 Preciso realizar uma Replicação em Cluster usando dois nodo multistate
 (master / slave), mas com Sistema Operacional Ubuntu e não Fedora.



O que você quer é utilizar replicação nativa (streaming replication)
master/slave do PostgreSQL. Por que você disse antes que isso não te
atendia?

Ah. E as ferramentas do link citado funcionam no Ubuntu. Já usei em Debian,
mas versões um pouco mais antigas que essas, só que creio não ter muita
diferença.

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida sobre Replicated Cluster no Postgres 9.3

[Sebastian Webber]

2014-12-02 10:02 GMT-02:00 Fabio Eckhardt 
fabioeckha...@universo.univates.br:

 Sebastian,

 Preciso realizar uma Replicação em Cluster usando dois nodo multistate
 (master / slave), mas com Sistema Operacional Ubuntu e não Fedora.


Como o Matheus comentou antes, a solução é o HotStandby de sempre.

Em poucas precisaria repedir o processo no link abaixo com S.O Ubuntu (e
 nao Fedora) :

 http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster

 Sabes se existe alguma documentação na web pra S.O Ubuntu ?


Se tem eu não conheço. Mas pelo que vi nesse manual, a unica coisa
especifica do SO é a instalação de pacotes e inicialização de serviços.
Tenho certeza que o Ubuntu (ou derivados do debian) tem um pacote e sintaxe
equivalente. Com um pouco de pesquisa você pode encontrar facilmente e eu
até te ajudo se tu me explicar o que você tem dificuldade.

Um abraço!

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida sobre Replicated Cluster no Postgres 9.3

[Sebastian Webber]

2014-12-01 8:48 GMT-02:00 Fabio Eckhardt fabioeckha...@universo.univates.br
:

 Sebastian,

 Sou sincero em lhe dizer, não sou muito fã de FEDORA. E atualmente a
 melhor documentação que existe é pra FEDORA.

 Sabes algum material na internet para UBUNTU (e postgres 9.3) para
 realizar uma a Replicação de Cluster com 2 servidores Postgres, isto é  2
 nodo multistate cluster. ???


Fábio,

Tu poderias ser mais específico com o que tu precisa fazer? Confesso que
não entendi o que tu precisas.


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Duvida sobre Replicated Cluster no Postgres 9.3

[Fabio Eckhardt]

​Bom Dia,

Gostaria de saber se algum ja implementou no Postgres 9.3 uma Replicação de
Cluster com 2 servidores Postgres, isto é  2 nodo multistate cluster.

Aonde é temos o seguinte cenário, temos 2 servidor atendendo as requisições
(e replicando para si mesmo) e uma IP Virtual este sim fica visivel para
todos mundo e apartir dele que realizada as consultas/insert.

Andei verificando e tem algum documentação para Postgres 9.1 para Fedora
(neste link: http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster). Saberia
me informar se existem algo para Postgres 9.3 em Ubuntu ?


Obs: Hot Standby e Streaming Replication com um servidor master e outro
slave não resolve o meu problema. No meu caso gostaria de ter 2 servidor
(se comunicando) e ip virtual que atendo as consultas/insert.

Algum poderia ajudar ?

​
​Obrigado !​

-- 

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

Re: [pgbr-geral] Duvida sobre Replicated Cluster no Postgres 9.3

[Sebastian Webber]

2014-11-28 8:57 GMT-02:00 Fabio Eckhardt fabioeckha...@universo.univates.br
:


 ​Bom Dia,

 Gostaria de saber se algum ja implementou no Postgres 9.3 uma Replicação
 de Cluster com 2 servidores Postgres, isto é  2 nodo multistate
 cluster.

 Aonde é temos o seguinte cenário, temos 2 servidor atendendo as
 requisições (e replicando para si mesmo) e uma IP Virtual este sim fica
 visivel para todos mundo e apartir dele que realizada as consultas/insert.



Até aqui, é uma pratica comum, aonde utilzamos o ip virtual para o slave
assumir em caso de parada, sem ter que reconfigurar os clientes.



 Andei verificando e tem algum documentação para Postgres 9.1 para Fedora
 (neste link: http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster).


Isso lembra tanto o RedHat Cluster Suite. Será que é uma solução similar?


 Saberia me informar se existem algo para Postgres 9.3 em Ubuntu ?


Acredito que o pacemaker também está disponível para o ubuntu. Com um pouco
de shell script dá pra chegar na mesma solução.

Obs: Hot Standby e Streaming Replication com um servidor master e outro
 slave não resolve o meu problema. No meu caso gostaria de ter 2 servidor
 (se comunicando) e ip virtual que atendo as consultas/insert.


Não entendi. Tu precisa que os selects sejam balanceados entre os 2
servidores e apenas um deles execute os Updates/Deletes/Inserts? ou apenas
quer utilizar 1 servidor de cada vez?


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com indice em campo booleano

[Tiago José Adami]

Em 19 de setembro de 2014 23:28, Wellington wm...@yahoo.com.br escreveu:
 Pessoal,

 em uma tabela foi criado um indice assim: campo = false.

 Quando eu rodo a consulta selecionando campo is false, o indice nao é
 utilizado.
 O indice so é utilizado se seleciono campo = false.
 Alguem saberia me explicar por que isso acontece ?

Esse é um recurso do PostgreSQL chamado índice parcial (ou /partial
index/ [1]). Se for utilizar esse recurso, você precisaria criar um
índices para os valores false e outro para os valores true. Dependendo
do número de registros da tabela, um índice simples (sem a clausula de
condição explícita) já é o bastante.

Resumindo: ao invés de criar o índice com uma condição (coluna =
valor), utilize apenas o nome da coluna.

CREATE INDEX indice ON tabela (nome_da_coluna)

Dá uma lida na documentação abaixo:

[1] http://www.postgresql.org/docs/9.3/static/indexes-expressional.html


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com indice em campo booleano

[Matheus de Oliveira]

2014-09-19 23:28 GMT-03:00 Wellington wm...@yahoo.com.br:

 em uma tabela foi criado um indice assim: campo = false.

 Quando eu rodo a consulta selecionando campo is false, o indice nao é
 utilizado.
 O indice so é utilizado se seleciono campo = false.
 Alguem saberia me explicar por que isso acontece ?


O operador IS e o operador de igualdade não são equivalentes. O operador de
igualdade considera valores iguais mas retorna NULL caso um dos operandos
seja NULL, já o IS considera exatamente iguais ignorando valores nulos,
como se NULL fosse um terceiro valor possível (e.g. no caso retorna FALSE
caso campo seja NULL ou TRUE, e TRUE caso o campo seja FALSE).

Para exemplificar, veja:

postgres=# SELECT false IS false, null::boolean IS false, false =
false, null::boolean = false;
 ?column? | ?column? | ?column? | ?column?
--+--+--+--
 t| f| t| (null)
(1 row)

Para índices parciais, sempre tente casar exatamente igual.

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com indice em campo booleano

[Tiago José Adami]

Em 20/09/2014 14:34, Matheus de Oliveira matioli.math...@gmail.com
escreveu:


 2014-09-19 23:28 GMT-03:00 Wellington wm...@yahoo.com.br:

 em uma tabela foi criado um indice assim: campo = false.

 Quando eu rodo a consulta selecionando campo is false, o indice nao é
utilizado.
 O indice so é utilizado se seleciono campo = false.
 Alguem saberia me explicar por que isso acontece ?


 O operador IS e o operador de igualdade não são equivalentes. O operador
de igualdade considera valores iguais mas retorna NULL caso um dos
operandos seja NULL, já o IS considera exatamente iguais ignorando valores
nulos, como se NULL fosse um terceiro valor possível (e.g. no caso retorna
FALSE caso campo seja NULL ou TRUE, e TRUE caso o campo seja FALSE).

 Para exemplificar, veja:

 postgres=# SELECT false IS false, null::boolean IS false, false =
false, null::boolean = false;
  ?column? | ?column? | ?column? | ?column?
 --+--+--+--
  t| f| t| (null)
 (1 row)

 Para índices parciais, sempre tente casar exatamente igual.

Ops, na ânsia de querer ajudar fiz uma leitura péssima e não percebi a
cláusula. Boa explicação, Matheus.

---
Tiago J. Adami
Sent from GMail
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com indice em campo booleano

[Matheus de Oliveira]

2014-09-20 14:42 GMT-03:00 Tiago José Adami adam...@gmail.com:

 Ops, na ânsia de querer ajudar fiz uma leitura péssima e não percebi a
 cláusula. Boa explicação, Matheus.


Acontece cara. Tranquilo.

:-)

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] duvida com indice em campo booleano

[Wellington]

Pessoal,

em uma tabela foi criado um indice assim: campo = false.

Quando eu rodo a consulta selecionando campo is false, o indice nao é 
utilizado.

O indice so é utilizado se seleciono campo = false.
Alguem saberia me explicar por que isso acontece ?


Desde ja, agradeço.
Wellington


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

Re: [pgbr-geral] Duvida em logica

[Ricardo]

Também achei que há um erro de modelagem e já estou providenciando consertar 
isso. Mas preciso achar um remendo para não deixar o sistema parado.


From: Tiago José Adami 
Sent: Monday, September 08, 2014 11:54 PM
To: PGBR 
Subject: Re: [pgbr-geral] Duvida em logica


On Sep 8, 2014 4:59 PM, Ricardo rica...@longomaquinas.com wrote:

 Boa tarde pessoal,
  
 Estou enrolado em achar um solução via trigger para este caso.
  
 Tenho duas tabelas, uma denominada “Produtos” e outra “Matéria Prima” com 
 o campo “Quantidade Atual”.
  
 Sempre que ocorre uma saída de produtos ocorre o gatilho em uma trigger 
 que faz a atualização do valor em “Quantidade Atual” na tabela “Produtos”e o 
 mesmo ocorre quando há uma saída de matéria prima na tabela “Matéria Prima”.

Possivelmente há um erro no conceito da modelagem (ou modelação, como alguns 
preferem).

Crie uma tabela separada para saldos de estoque. E verifique se matéria prima 
também pode ser um produto, assim você teria uma única tabela para produtos e 
matérias primas, diferenciando cada tipo por um atributo, e uma única tabela 
para saldo de estoque.

---
Tiago J. Adami
Sent from GMail




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





Nenhum vírus encontrado nessa mensagem.
Verificado por AVG - www.avgbrasil.com.br
Versão: 2014.0.4765 / Banco de dados de vírus: 4015/8177 - Data de Lançamento: 
09/08/14
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida em logica

[Mário Agostinho Reis]

Claro, só pode! Então não é o que chama de ligações circulares. A
actualiza B mas B logo que é actualizado, vai actualizar A e nunca
mais saímos daqui, porque as actualizações disparam os gatilhos.
Agora não percebi a necessidade de fazer assim.
Para ultrapassar este  loop se fosse você experimentava por o
campo:“Quantidade
Atual” (+ um campo ID) numa 3.ª tabela actualizável pelos gatilhos de
qualquer das duas primeiras e retirava os gatilhos que fazem actualizações
reciprocas.
Porém, esta 3.ª tabela não pode fazer essas actualizações deve limitar-me
a recebe-las.
Tem um problema, você tem de fazer mais um acesso. E, daí? O Posgres
resolve isso para V. num àpice.
Nas consultas/validações V. pode construir uma view que lhe permite ter
sempre on line “Quantidade Atual”  quer de produtos quer de Matéria Prima.


Com os meus melhores cumprimentos
O Secretário Geral da ACRA
Mário Agostinho  Reis

Esta mensagem contém informação de natureza confidencial e é
exclusivamente dirigida ao(s) destinatário(s) indicado(s). Se, por engano,
receber este email agradecemos que não o copie nem o reenvie e que nos
notifique do ocorrido através do email de resposta.

No dia 8 de Setembro de 2014 às 19:59, Ricardo rica...@longomaquinas.com
escreveu:

   Boa tarde pessoal,

 Estou enrolado em achar um solução via trigger para este caso.

 Tenho duas tabelas, uma denominada “Produtos” e outra “Matéria Prima”
 com o campo “Quantidade Atual”.

 Sempre que ocorre uma saída de produtos ocorre o gatilho em uma
 trigger que faz a atualização do valor em “Quantidade Atual” na tabela
 “Produtos”e o mesmo ocorre quando há uma saída de matéria prima na tabela
 “Matéria Prima”.

 Porem tem um campo na tabela “Produtos” onde pode ser amarrado uma
 “Matéria Prima”. Sendo assim se ocorrer uma saída de produtos, além de
 fazer atualização da “Quantidade Atual” na tabela “Produtos” tem que fazer
 na tabela “Matéria Prima” também. E se ocorrer uma saída na tabela “Matéria
 Prima” tem que atualizar a “Quantidade Atual” nas duas tabelas também.
 O problema é que quando é executado o trigger que faz o update de uma
 tabela, essa tabela executa um trigger para atualizar a outra e fica em um
 loop infinito.

 Não sei se o melhor caminho é criar um campo como semáforo, fico com
 receio desse semáforo travar e não ocorrer mais atualizações.

 Abraços
 Ricardo

 ___
 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] Duvida em logica

[Ricardo]

Boa tarde pessoal,

Estou enrolado em achar um solução via trigger para este caso.

Tenho duas tabelas, uma denominada “Produtos” e outra “Matéria Prima” com o 
campo “Quantidade Atual”.

Sempre que ocorre uma saída de produtos ocorre o gatilho em uma trigger que 
faz a atualização do valor em “Quantidade Atual” na tabela “Produtos”e o mesmo 
ocorre quando há uma saída de matéria prima na tabela “Matéria Prima”.

Porem tem um campo na tabela “Produtos” onde pode ser amarrado uma “Matéria 
Prima”. Sendo assim se ocorrer uma saída de produtos, além de fazer atualização 
da “Quantidade Atual” na tabela “Produtos” tem que fazer na tabela “Matéria 
Prima” também. E se ocorrer uma saída na tabela “Matéria Prima” tem que 
atualizar a “Quantidade Atual” nas duas tabelas também.
O problema é que quando é executado o trigger que faz o update de uma 
tabela, essa tabela executa um trigger para atualizar a outra e fica em um loop 
infinito.

Não sei se o melhor caminho é criar um campo como semáforo, fico com receio 
desse semáforo travar e não ocorrer mais atualizações.

Abraços
Ricardo___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida em logica

[Tiago José Adami]

On Sep 8, 2014 4:59 PM, Ricardo rica...@longomaquinas.com wrote:

 Boa tarde pessoal,

 Estou enrolado em achar um solução via trigger para este caso.

 Tenho duas tabelas, uma denominada “Produtos” e outra “Matéria Prima”
com o campo “Quantidade Atual”.

 Sempre que ocorre uma saída de produtos ocorre o gatilho em uma
trigger que faz a atualização do valor em “Quantidade Atual” na tabela
“Produtos”e o mesmo ocorre quando há uma saída de matéria prima na tabela
“Matéria Prima”.

Possivelmente há um erro no conceito da modelagem (ou modelação, como
alguns preferem).

Crie uma tabela separada para saldos de estoque. E verifique se matéria
prima também pode ser um produto, assim você teria uma única tabela para
produtos e matérias primas, diferenciando cada tipo por um atributo, e uma
única tabela para saldo de estoque.

---
Tiago J. Adami
Sent from GMail
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida com Vacuum Full

[Flavio Henrique Araque Gurgel]

tenho uma duvida: É possivel identificar quais tabelas do banco estao
inchadas, ou seja, que sofreram muitas alteracoes e que necessitam de


https://wiki.postgresql.org/wiki/Show_database_bloat


vacuum full ?


Normalmente, nunca, mas há casos excepcionais.

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

[pgbr-geral] Duvida com Vacuum Full

[Wellington]

Boa noite pessoal,

tenho uma duvida: É possivel identificar quais tabelas do banco estao 
inchadas, ou seja, que sofreram muitas alteracoes e que necessitam de 
vacuum full ?



Obrigado.
Wellington


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

[pgbr-geral] Duvida em escrita de SQL

[Pedro B. Alves]

Pessoal gostaria de uma dica dos mais esperientes:

Qual a diferença para o banco na escrita destes dois SQLs?

SELECT twe.*
 , (SELECT descricao FROM tespecializacoes WHERE idespecializacao =
twe.idespecializacao) AS especializacao
  FROM tworkflowetapas twe


SELECT twe.*
  FROM tworkflowetapas twe
  LEFT JOIN tespecializacoes esp ON (twe.idespecializacao =
esp.idespecializacao)

Tem alguma diferença de performance, quebra de indices, etc?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida em escrita de SQL

[Flavio Henrique Araque Gurgel]

Pessoal gostaria de uma dica dos mais esperientes:

Qual a diferença para o banco na escrita destes dois SQLs?

SELECT twe.*
  , (SELECT descricao FROM tespecializacoes WHERE idespecializacao =
twe.idespecializacao) AS especializacao
   FROM tworkflowetapas twe


SELECT twe.*
   FROM tworkflowetapas twe
   LEFT JOIN tespecializacoes esp ON (twe.idespecializacao =
esp.idespecializacao)

Tem alguma diferença de performance, quebra de indices, etc?


Dependendo da versão do PostgreSQL, se você fizer um EXPLAIN ANALYZE de 
cada uma delas, provavelmente o plano será exatamente o mesmo.


[]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] Duvida em escrita de SQL

[Pedro B. Alves]

 Dependendo da versão do PostgreSQL, se você fizer um EXPLAIN ANALYZE de
 cada uma delas, provavelmente o plano será exatamente o mesmo.


Utilizo a versão 9.3.x

executei o EXPLAIN..

SELECT twe.*
 , (SELECT descricao FROM tespecializacoes WHERE idespecializacao =
twe.idespecializacao) AS especializacao
  FROM tworkflowetapas twe


Seq Scan on tworkflowetapas twe  (cost=0.00..16.36 rows=14 width=30)
(actual time=0.040..0.142 rows=14 loops=1)
  SubPlan 1
-  Seq Scan on tespecializacoes  (cost=0.00..1.09 rows=1 width=218)
(actual time=0.003..0.004 rows=1 loops=14)
  Filter: (idespecializacao = twe.idespecializacao)
  Rows Removed by Filter: 7
Total runtime: 0.220 ms




SELECT twe.*
  FROM tworkflowetapas twe
  LEFT JOIN tespecializacoes esp ON (twe.idespecializacao =
esp.idespecializacao)


Seq Scan on tworkflowetapas twe  (cost=0.00..1.14 rows=14 width=30)
(actual time=0.013..0.016 rows=14 loops=1)
Total runtime: 0.068 ms
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida em escrita de SQL

[Rafael Fialho]

2014-08-12 11:05 GMT-03:00 Pedro B. Alves pedroalve...@gmail.com:



 Dependendo da versão do PostgreSQL, se você fizer um EXPLAIN ANALYZE de
 cada uma delas, provavelmente o plano será exatamente o mesmo.


 Utilizo a versão 9.3.x

 executei o EXPLAIN..

 SELECT twe.*
  , (SELECT descricao FROM tespecializacoes WHERE idespecializacao =
 twe.idespecializacao) AS especializacao
   FROM tworkflowetapas twe


 Seq Scan on tworkflowetapas twe  (cost=0.00..16.36 rows=14 width=30)
 (actual time=0.040..0.142 rows=14 loops=1)
   SubPlan 1
 -  Seq Scan on tespecializacoes  (cost=0.00..1.09 rows=1 width=218)
 (actual time=0.003..0.004 rows=1 loops=14)
   Filter: (idespecializacao = twe.idespecializacao)
   Rows Removed by Filter: 7
 Total runtime: 0.220 ms




 SELECT twe.*
   FROM tworkflowetapas twe
   LEFT JOIN tespecializacoes esp ON (twe.idespecializacao =
 esp.idespecializacao)


 Seq Scan on tworkflowetapas twe  (cost=0.00..1.14 rows=14 width=30)
 (actual time=0.013..0.016 rows=14 loops=1)
 Total runtime: 0.068 ms


O tempo da segunda consulta é menor, pois o banco está ignorando a junção.
Você tem que utilizar pelo menos algum campo da tabela para que os dois
planos de execução sejam realmente iguais, e retornem a mesma coisa.

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

Re: [pgbr-geral] Duvida em escrita de SQL

[Osvaldo Kussama]

2014-08-12 11:05 GMT-03:00, Pedro B. Alves pedroalve...@gmail.com:



 Dependendo da versão do PostgreSQL, se você fizer um EXPLAIN ANALYZE de
 cada uma delas, provavelmente o plano será exatamente o mesmo.


 Utilizo a versão 9.3.x

 executei o EXPLAIN..

 SELECT twe.*
  , (SELECT descricao FROM tespecializacoes WHERE idespecializacao =
 twe.idespecializacao) AS especializacao
   FROM tworkflowetapas twe


 Seq Scan on tworkflowetapas twe  (cost=0.00..16.36 rows=14 width=30)
 (actual time=0.040..0.142 rows=14 loops=1)
   SubPlan 1
 -  Seq Scan on tespecializacoes  (cost=0.00..1.09 rows=1 width=218)
 (actual time=0.003..0.004 rows=1 loops=14)
   Filter: (idespecializacao = twe.idespecializacao)
   Rows Removed by Filter: 7
 Total runtime: 0.220 ms




 SELECT twe.*
   FROM tworkflowetapas twe
   LEFT JOIN tespecializacoes esp ON (twe.idespecializacao =
 esp.idespecializacao)


 Seq Scan on tworkflowetapas twe  (cost=0.00..1.14 rows=14 width=30)
 (actual time=0.013..0.016 rows=14 loops=1)
 Total runtime: 0.068 ms



Creio que no segundo SELECT faltou esp.descricao na lista de campos,
senão não haveria necessidade da tabela tespecializacoes (como
concluiu o otimizador).

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] Duvida em escrita de SQL

[Bruno Silva]

On Tue, Aug 12, 2014 at 11:05 AM, Pedro B. Alves pedroalve...@gmail.com
wrote:

 SELECT twe.*
   FROM tworkflowetapas twe
   LEFT JOIN tespecializacoes esp ON (twe.idespecializacao =
 esp.idespecializacao)


Por que isso se você não usa nada da tabela tespecializacoes e ainda a usa
como LEFT JOIN?

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

Re: [pgbr-geral] Duvida em escrita de SQL

[Pedro B. Alves]

 Creio que no segundo SELECT faltou esp.descricao na lista de campos,
 senão não haveria necessidade da tabela tespecializacoes (como
 concluiu o otimizador).


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

Re: [pgbr-geral] Duvida em escrita de SQL

[Wellington]

Pessoal gostaria de uma dica dos mais esperientes:

Qual a diferença para o banco na escrita destes dois SQLs?

SELECT twe.*
  , (SELECT descricao FROM tespecializacoes WHERE idespecializacao =
twe.idespecializacao) AS especializacao
   FROM tworkflowetapas twe

SELECT twe.*
   FROM tworkflowetapas twe
   LEFT JOIN tespecializacoes esp ON (twe.idespecializacao =
esp.idespecializacao)

Tem alguma diferença de performance, quebra de indices, etc?


Acredito que o LEFT JOIN valeria a pena se fosse para buscar 2 ou mais 
campos na tabela tespecializacoes, o SQL abaixo seria menos performatico, ou 
estou errado ?


SELECT twe.*
 , (SELECT descricao FROM tespecializacoes WHERE 
idespecializacao = twe.idespecializacao) AS especializacao,
 , (SELECT outro_campo FROM tespecializacoes WHERE 
idespecializacao = twe.idespecializacao) AS exemplo
  FROM tworkflowetapas twe 


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

[pgbr-geral] Duvida sobre schema em funcao

[Wellington]

Pessoal,

quando eu executo o comando SET search_path TO nome_schema dentro de uma 
funcao, em uma mesma sessao, o SGDB nao altera o search_path nos comandos 
executados apos o primeiro, me parece que o schema fica em um tipo de cache.


Duvida: Existe alguma forma de contornar isso?

Sei que posso usar o comando Execute passando o schema em uma variavel, 
mas gostaria de evitar fazer comandos sql concatenando Strings.



Desde ja, agradeco.
Wellington 


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

Re: [pgbr-geral] Duvida sobre schema em funcao

[Flavio Henrique Araque Gurgel]

quando eu executo o comando SET search_path TO nome_schema dentro de
uma funcao, em uma mesma sessao, o SGDB nao altera o search_path nos
comandos executados apos o primeiro, me parece que o schema fica em um
tipo de cache.

Duvida: Existe alguma forma de contornar isso?

Sei que posso usar o comando Execute passando o schema em uma
variavel, mas gostaria de evitar fazer comandos sql concatenando Strings.


Você parece ter misturado as coisas.
Uma vez feito um SET, isso vai valer até o final da sessão.
Se chamado dentro de uma transação, será desfeito por um rollback.

Por outro lado, dentro de um execute, o search_path da sessão não é 
utilizado.


Só se usa execute quando você precisa de SQL dinâmico, ou seja, a 
consulta e nomes de tabelas e colunas são variáveis. Verifique se sua 
função realmente precisa de execute, se quiser passe o código aqui pra 
gente ver e te ajudar melhor.
Todavia, você pode passar o search_path dentro do execute, colocar um 
ponto-e-vírgula e sua consulta logo após.


[]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] Duvida sobre schema em funcao

[Matheus de Oliveira]

2014-07-25 3:15 GMT-03:00 Wellington wm...@yahoo.com.br:

  quando eu executo o comando SET search_path TO nome_schema dentro de
 uma funcao, em uma mesma sessao, o SGDB nao altera o search_path nos
 comandos executados apos o primeiro, me parece que o schema fica em um tipo
 de cache.

 Duvida: Existe alguma forma de contornar isso?



O que creio que está acontecendo é que quando você executa uma função
PL/pgSQL a primeira vez é feito o cache dos planos de execução, e esse
cache utiliza o oid das relações e não o nome exato que você passou. Assim
sendo, na primeira execução será usada as tabelas respeitando o search_path
informado, nas próximas execuções, mesmo alterando o search_path, ele irá
continuar com o plano de execução com o search_path anterior.

Agora. O comportamento quanto a isso foi alterado na versão 9.3 [1]:

Force cached plans to be replanned if the search_path changes (Tom Lane)

Previously, cached plans already generated in the current session were not
redone if the query was re-executed with a new search_path setting,
resulting in surprising behavior.

Ou seja, sempre que o search_path é alterado, os planos armazenados são
descartados. O efeito que isso causa é que se você altera sempre o
search_path, sempre irás ter que fazer o planejamento dos planos e não
utilizará o cache.


Sei que posso usar o comando Execute passando o schema em uma variavel,
 mas gostaria de evitar fazer comandos sql concatenando Strings.



Sim. Você pode, na verdade nem precisa passar o schema como variável, as
consultas executadas pelo EXECUTE não têm os planos cacheados, basta
executá-las então que o search_path corrente será sempre respeitado. As
outras alternativas são: clonar sua função em cada esquema ou atualizar
para a 9.3.


[1] http://www.postgresql.org/docs/9.3/static/release-9-3.html

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida sobre schema em funcao

[Matheus de Oliveira]

2014-07-25 6:30 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com:

 Por outro lado, dentro de um execute, o search_path da sessão não é
 utilizado.



Opa. Até onde sei o search_path é respeitado dentro de um EXECUTE sim. A
não ser que seja um comportamento que tenha sido alterado nas versões mais
recentes.


 Só se usa execute quando você precisa de SQL dinâmico, ou seja, a consulta
 e nomes de tabelas e colunas são variáveis.


Eu vejo mais um uso para atingir melhor performance, algumas vezes não
queremos um plano genérico, e é melhor colocar uma consulta num EXECUTE do
que executar diretamente (evitando o plano de execução sem os valores
reais, a.k.a, plano genérico). Isso é comum quando a tabela envolvida está
particionada (basicamente um plano genérico vai ter que unir todas tabelas
filhas, mesmo que a consulta use a chave do particionamento). Entretanto, a
partir da versão 9.2 os planos preparados ficaram melhores (basicamente é
feito um re-planejamento no momento da execução em determinadas
situações) e não é mais comum necessitar de recorrer ao EXECUTE para tanto
(apesar de que já ouvi casos onde ainda é necessário, já que as
determinadas situações são difíceis de prever).

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Duvida tempo de processamento procedure

[Anderson Marques]

Bom dia, pessoal estamos desenvolvendo um sistema de gerenciamento de
estoque, porem surgiu essa duvidaa procedure pode travar o sistema
dependendo da demanda de requisição simultânea, tipo umas 1500 requisições
simultâneas?

o problema que estamos resolvendo com a procedure é a movimentação do
estoque
, na entrada e saída, fizemos uma simulação onde dois usuários trabalham no
mesmo item fazendo a saida, do modo que está implementado apenas no código
ambos trabalharam o mesmo valor de estoque só que o estoque para o 2ª ja
não era o mesmo.

a procedure é a melhor implementação para resolver isso?

desde ja agradeço a ajuda.

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

Re: [pgbr-geral] Duvida tempo de processamento procedure

[Tiago Adami]

Em 30 de janeiro de 2014 10:02, Anderson Marques
jackvalant...@gmail.com escreveu:
 Bom dia, pessoal estamos desenvolvendo um sistema de gerenciamento de
 estoque, porem surgiu essa duvidaa procedure pode travar o sistema
 dependendo da demanda de requisição simultânea, tipo umas 1500 requisições
 simultâneas?

1500 requisições simultâneas (a.k.a ao mesmo tempo) é algo realmente
grande. Cada requisição irá consumir 1 núcleo de CPU, logo haverá
distribuição entre os cores existentes, criando uma fila. Isso não
implica em travar, exceto se a sua procedure concorrer pelos mesmos
registros de uma tabela. Leia sobre níveis de isolamento (ou isolação,
como alguns dizem) [1] para ter uma idéia do que pode ocorrer.

 o problema que estamos resolvendo com a procedure é a movimentação do
 estoque
 , na entrada e saída, fizemos uma simulação onde dois usuários trabalham no
 mesmo item fazendo a saida, do modo que está implementado apenas no código
 ambos trabalharam o mesmo valor de estoque só que o estoque para o 2ª ja não
 era o mesmo.

 a procedure é a melhor implementação para resolver isso?

Levando em consideração a aquisição de LOCK corretamente - usando os
conceitos de [1] - você poderá tratar isso diretamente na aplicação
sem criar objetos de banco. Exceto se existir algum outro agente além
do seu aplicativo que altere valores que impliquem na modificação de
saldos eu vejo que através de um trigger e uma procedure você obterá
resultados mais satisfatórios, porém há de se preocupar com os limites
da regra de negócio - para não misturar metade no programa ou metade
no banco de dados.

O que você precisa é alterar o isolamento da transação no momento de
alterar o registro com saldo com [2] [3]:

1) Selecionar o registro a ser alterado com SELECT ... FOR UPDATE;
2) Alterar o registro pela procedure chamada por trigger, ou, pelo programa;
3) COMMIT na transação pela aplicação;

Quando 2 transações tentarem selecionar o mesmo registro pelo SELECT
... FOR UPDATE, a primeira que tiver acesso ao registro irá conseguir.
Enquanto essa primeira transação não for encerrada (COMMIT ou
ROLLBACK), qualquer outra transação que executar o SELECT ... FOR
UPDATE sobre o mesmo registro (ou vários, incluindo o registro que já
está resevado) irá ficar em LOCK WAIT.

Outra opção é alterar o nível de isolamento e usando cursores dentro
de uma procedure para não precisará usar o SELECT ... FOR UPDATE.

[1] http://www.postgresql.org/docs/9.3/static/transaction-iso.html
[2] http://www.postgresql.org/docs/9.3/static/sql-set-transaction.html
[3] http://www.postgresql.org/docs/9.3/static/explicit-locking.html




TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Matheus de Oliveira]

2014/1/19 Eloi e...@openmailbox.org


  É, parece que você criou uma bagunça com as aspas mesmo... Acho que vai
  ficar mais fácil refazer a função do que ajustar cada problema nela. Já
 que
  vamos refazer, que tal adicionar algumas dicas de ouro? ;-)
 
 
  Bom, primeiro, veja o modelo que criei (não testei, então pode ter algum
  erro que eu não tenha visto):
 
  CREATE OR REPLACE FUNCTION wosis.fun_create_sequence(sch text)
  RETURNS text
  LANGUAGE plpgsql VOLATILE
  AS
  $BODY$
  DECLARE
  row record;
  BEGIN
  FOR row IN
  SELECT table_name, table_name||'_id' AS id_name, 0 AS
 next_value
  FROM information_schema.tables
  WHERE table_schema = sch
  AND  table_type = 'BASE TABLE'
  ORDER BY table_name
  LOOP
  EXECUTE
  format('SELECT max(%I)+1 FROM %I.%I', row.id_name, sch,
  row.table_name)
  INTO row.next_value;
  EXECUTE
  format(
  'CREATE SEQUENCE %I.%I START %L OWNED BY %I.%I.%I;',
  sch,
  row.table_name||'_'||row.id_name||'_seq',
 row.next_value -- faltava
  sch,
  row.table_name,
  row.id_name
  );
 EXECUTE
 format(
  'ALTER TABLE %I.%I ALTER COLUMN %I SET DEFAULT
  nextval(%L);', -- AQUI FALTAVA A VIRGULA
  sch,
  row.table_name,
  row.id_name,
  row.table_name||'_'||row.id_name||'_seq'
  );
  END LOOP;
  RETURN 'Sequences were created';
  END;
  $BODY$;
 
  Agora vejamos... Em primeiro lugar eu não usei uma tabela temporário,
  simplesmente porque não vi sentido, e acho que acabou deixando a função
  mais confusa ainda. Ao invés disso eu apenas naveguei no resultado da
  consulta à view information_schema.tables. Repare também que não usei
  consulta dinâmica (comando EXECUTE) nesta consulta, simplesmente porque
 não
  é necessário e recomendo evitar o uso de EXECUTE ao máximo.
 
  Em segundo lugar, precisamos de três comandos, um para fazer um `SELECT
  max` para recuperar o maior valor, outro para criar a sequência e o
 último
  para alterar o DEFAULT da tabela. Em ambos os casos a função format ajuda
  bastante, e não precisa de tantos quote_ident's, que podem ser confusos.
 
  Em [1] há um comparativo legal entre format e quote_ident. Veja lá e
 poste
  dúvidas que sobrarem aqui.
 
  Por fim, adicionei a cláusula OWNED BY no CREATE SEQUENCE, para deixar
  idêntico ao que o pseudo-tipo SERIAL faz, e é uma boa prática para
 futuras
  manutenções.
 
  Só tenho mais um comentário. Esses comandos estão (talvez erroneamente)
  assumindo que toda tabela tem um campo nome da tabela_id, mas talvez
  faça parte do seu modelo, mas eu evitaria isso, a não ser que seja algo
  executado somente numa tarefa administrativa.
 
  Ufa... Leia com calma, tentei ser o mais claro possível. ^^
 
  [1]
 
 http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-QUOTE-LITERAL-EXAMPLE
 
 
  Atenciosamente,

 Obrigado a todos pelas respostas e desculpar-me por não responder antes.

 Gostei das dicas do 'format()', muito parecido ao python e também do
 'INTO row.next_value', não conhecia. E sem duvida que conceptualmente a
 função ficou muito melhor, não complicou. Parece que terei de rever
 todas as minhas funções que estive a escrever na ultima semana.

 Sim, todas as tabelas tem o nome da tabela_id, fiz uma função para
 que assim fosse. E sim, é apenas uma tarefa administrativa num esquema
 com 70 tabelas.



Ok. Fico mais tranquilo agora, +D.



 Foi necessário uns retoques minimos, uma virgula que falatva e passar o
 valor de row.next_value.



É, eu só digitei, não testei nada, então podia ter erros.



 Agora só falta um detalhe, esta a passar o valor de 'next_value' como
 texto e salta erro. Tentei o 'cast' (::int) mas parece-me que isso é
 apenas para o puro SQL.

 ERROR:  syntax error at or near '25476'
 LINE 1: ...E SEQUENCE wosis.class_fao_class_fao_id_seq START '25476' OW...
  ^
 QUERY:  CREATE SEQUENCE wosis.class_fao_class_fao_id_seq START '25476'
 OWNED BY wosis.class_fao.class_fao_id;
 CONTEXT:  PL/pgSQL function fun_create_sequence line 19 at EXECUTE
 statement

 Como faço para passar o valor como inteiro?



Realmente, o next_value devia ser passado como inteiro, não literal. Para
resolver isso, basta usar o %s ao invés de %L. Este irá alocar o valor
diretamente, por isso recomendo um CAST no parâmetro (ele já é inteiro, mas
é só para garantir 100% que não haverá erros):

   format('CREATE SEQUENCE %I.%I START %s OWNED BY %I.%I.%I;',  ,
row.next_value::int, ...);



 Muito obrigado a todos 

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Eloi Ribeiro]

Como faço para passar o valor como inteiro?


Realmente, o next_value devia ser passado como inteiro, não literal.
Para resolver isso, basta usar o %s ao invés de %L. Este irá alocar
o valor diretamente, por isso recomendo um CAST no parâmetro (ele já
é inteiro, mas é só para garantir 100% que não haverá erros):

   format('CREATE SEQUENCE %I.%I START %s OWNED BY %I.%I.%I;', 
, row.next_value::int, ...);



OK! Mudando o %L por %s já passa o valor como inteiro e funciona (mesmo 
sem o cast ::int). A função ficou assim.


CREATE OR REPLACE FUNCTION wosis.fun_create_sequence(sch text)
RETURNS text
LANGUAGE plpgsql VOLATILE
AS
$BODY$
DECLARE
row record;
BEGIN
FOR row IN
SELECT table_name, table_name||'_id' AS id_name, 0 AS 
next_value

FROM information_schema.tables
WHERE table_schema = sch
AND  table_type = 'BASE TABLE'
ORDER BY table_name
LOOP
EXECUTE
format(
   'SELECT max(%I)+1 FROM %I.%I;',
   row.id_name,
   sch,
   row.table_name)
   INTO row.next_value;
EXECUTE
format(
   'CREATE SEQUENCE %I.%I START %s OWNED BY 
%I.%I.%I;',

   sch,
   row.table_name||'_'||row.id_name||'_seq',
   row.next_value,
   sch,
   row.table_name,
   row.id_name
  );
   EXECUTE
   format(
  'ALTER TABLE %I.%I ALTER COLUMN %I SET DEFAULT 
nextval(%L);',

  sch,
  row.table_name,
  row.id_name,
  sch || '.' 
||row.table_name||'_'||row.id_name||'_seq'

 );
END LOOP;
RETURN 'Sequences were created';
END;
$BODY$;
ALTER FUNCTION wosis.fun_create_sequence(text) OWNER TO postgres;
COMMENT ON FUNCTION wosis.fun_create_sequence(text) IS 'Create sequences 
in all tables in a given schema';



Muito obrigado pela ajuda!

[]'s

Eloi

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

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Eloi]

 É, parece que você criou uma bagunça com as aspas mesmo... Acho que vai
 ficar mais fácil refazer a função do que ajustar cada problema nela. Já que
 vamos refazer, que tal adicionar algumas dicas de ouro? ;-)


 Bom, primeiro, veja o modelo que criei (não testei, então pode ter algum
 erro que eu não tenha visto):

 CREATE OR REPLACE FUNCTION wosis.fun_create_sequence(sch text)
 RETURNS text
 LANGUAGE plpgsql VOLATILE
 AS
 $BODY$
 DECLARE
 row record;
 BEGIN
 FOR row IN
 SELECT table_name, table_name||'_id' AS id_name, 0 AS next_value
 FROM information_schema.tables
 WHERE table_schema = sch
 AND  table_type = 'BASE TABLE'
 ORDER BY table_name
 LOOP
 EXECUTE
 format('SELECT max(%I)+1 FROM %I.%I', row.id_name, sch,
 row.table_name)
 INTO row.next_value;
 EXECUTE
 format(
 'CREATE SEQUENCE %I.%I START %L OWNED BY %I.%I.%I;',
 sch,
 row.table_name||'_'||row.id_name||'_seq',
row.next_value -- faltava
 sch,
 row.table_name,
 row.id_name
 );
EXECUTE
format(
 'ALTER TABLE %I.%I ALTER COLUMN %I SET DEFAULT
 nextval(%L);', -- AQUI FALTAVA A VIRGULA
 sch,
 row.table_name,
 row.id_name,
 row.table_name||'_'||row.id_name||'_seq'
 );
 END LOOP;
 RETURN 'Sequences were created';
 END;
 $BODY$;

 Agora vejamos... Em primeiro lugar eu não usei uma tabela temporário,
 simplesmente porque não vi sentido, e acho que acabou deixando a função
 mais confusa ainda. Ao invés disso eu apenas naveguei no resultado da
 consulta à view information_schema.tables. Repare também que não usei
 consulta dinâmica (comando EXECUTE) nesta consulta, simplesmente porque não
 é necessário e recomendo evitar o uso de EXECUTE ao máximo.

 Em segundo lugar, precisamos de três comandos, um para fazer um `SELECT
 max` para recuperar o maior valor, outro para criar a sequência e o último
 para alterar o DEFAULT da tabela. Em ambos os casos a função format ajuda
 bastante, e não precisa de tantos quote_ident's, que podem ser confusos.

 Em [1] há um comparativo legal entre format e quote_ident. Veja lá e poste
 dúvidas que sobrarem aqui.

 Por fim, adicionei a cláusula OWNED BY no CREATE SEQUENCE, para deixar
 idêntico ao que o pseudo-tipo SERIAL faz, e é uma boa prática para futuras
 manutenções.

 Só tenho mais um comentário. Esses comandos estão (talvez erroneamente)
 assumindo que toda tabela tem um campo nome da tabela_id, mas talvez
 faça parte do seu modelo, mas eu evitaria isso, a não ser que seja algo
 executado somente numa tarefa administrativa.

 Ufa... Leia com calma, tentei ser o mais claro possível. ^^

 [1]
 http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-QUOTE-LITERAL-EXAMPLE


 Atenciosamente,

Obrigado a todos pelas respostas e desculpar-me por não responder antes.

Gostei das dicas do 'format()', muito parecido ao python e também do
'INTO row.next_value', não conhecia. E sem duvida que conceptualmente a
função ficou muito melhor, não complicou. Parece que terei de rever
todas as minhas funções que estive a escrever na ultima semana.

Sim, todas as tabelas tem o nome da tabela_id, fiz uma função para
que assim fosse. E sim, é apenas uma tarefa administrativa num esquema
com 70 tabelas.

Foi necessário uns retoques minimos, uma virgula que falatva e passar o
valor de row.next_value.

Agora só falta um detalhe, esta a passar o valor de 'next_value' como
texto e salta erro. Tentei o 'cast' (::int) mas parece-me que isso é
apenas para o puro SQL.

ERROR:  syntax error at or near '25476'
LINE 1: ...E SEQUENCE wosis.class_fao_class_fao_id_seq START '25476' OW...
 ^
QUERY:  CREATE SEQUENCE wosis.class_fao_class_fao_id_seq START '25476'
OWNED BY wosis.class_fao.class_fao_id;
CONTEXT:  PL/pgSQL function fun_create_sequence line 19 at EXECUTE
statement

Como faço para passar o valor como inteiro?

Muito obrigado a todos pelas sugestões, correções e explicações.

Eloi



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

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Rafael Fialho Corrêa]

 Como faço para passar o valor como inteiro?


Segue exemplo retirado da documentação:

EXECUTE format('UPDATE tbl SET %I = $1 WHERE key = $2', colname)
USING newvalue, keyvalue;

Vide [1] 39.5.4. Executing Dynamic Commands em caso de dúvidas.
[]'s

[1]:
http://www.postgresql.org/docs/9.2/interactive/plpgsql-statements.html#PLPGSQL-QUOTE-LITERAL-EXAMPLE
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Eloi Ribeiro]

Ola a todos,

Estou a tentar criar uma função que crie sequencias em todas as tabelas 
num determinado esquema e não consigo avançar por causa das aspas dentro 
de aspas, alguém pode dar uma ajuda.


Aqui está o código, e o problema com as aspas esta no primeiro e no 
terceiro EXECUTE:


CREATE OR REPLACE FUNCTION wosis.fun_create_sequence(sch text)
  RETURNS text AS
$BODY$
DECLARE
row record;
BEGIN
EXECUTE '  CREATE TEMP TABLE tmp AS
   SELECT table_name, table_name||_id' AS id_name, 0 AS 
next_value

   FROM information_schema.tables
   WHERE table_schema = sch
   AND  table_type = 'BASE TABLE'
   ORDER BY table_name;';
FOR row IN
 SELECT table_name, id_name FROM tmp ORDER BY table_name
LOOP
EXECUTE 'UPDATE tmp SET next_value = (SELECT max(' || 
quote_ident(row.id_name) || ')+1 FROM ' || quote_ident(sch) || '.' || 
quote_ident(row.table_name) || ') WHERE table_name = ' || 
quote_ident(row.table_name) || ';'

END LOOP;
FOR row IN
 SELECT table_name, id_name, next_value FROM tmp ORDER BY table_name
LOOP
EXECUTE 'CREATE SEQUENCE ' || quote_ident(row.table_name) || '_' 
|| quote_ident(row.id_name) || '_seq START ' || 
quote_ident(row.next_value) || ';'
EXECUTE 'ALTER TABLE ' || quote_ident(sch) || '.' || 
quote_ident(row.table_name) || ' ALTER COLUMN ' || 
quote_ident(row.id_name) || ' SET DEFAULT nextval( ' || 
quote_ident(row.table_name) || '_' || quote_ident(row.id_name) || 
'_seq);'

END LOOP;
RETURN 'Sequences were created';
END;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION wosis.fun_create_sequence(text) OWNER TO postgres;
COMMENT ON FUNCTION wosis.fun_create_sequence(text) IS 'Create sequences 
in all tables from a given schema';


Obrigado,

--
Eloi Ribeiro
GIS Analyst / Programmer
51.9871, 5.6661
flavors.me/eloiribeiro
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Heloisa Fernanda]

Olá!

Use: EXECUTE $qualquercoisa$SELECT $qualquercoisa$||_variavel||$qualquercoisa$ 
FROM TABELA$qualquercoisa$;

Ou seja, troque as aspas por $qualquercoisa$___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Anderson Abreu]

Exemplificando melhor


 EXECUTE '  CREATE TEMP TABLE tmp AS
   SELECT table_name, table_name||_id AS id_name, 0 AS
next_value
   FROM information_schema.tables
   WHERE table_schema = sch
   AND  table_type = ''BASE TABLE''
   ORDER BY table_name;';




Atenciosamente,

Anderson Abreu
andersonab...@gmail.com
(61) 8157-6657
OOAD, RUP, SOA, Jboss, IIS
.Net, PHP, CFM, ASP, JAVA
McAffee Partner - Microsoft Partner
MySQL, Oracle, PostgreSQL, SQL Server, DB2, SyBase


2014/1/17 Eloi Ribeiro e...@openmailbox.org

 Ola a todos,

 Estou a tentar criar uma função que crie sequencias em todas as tabelas
 num determinado esquema e não consigo avançar por causa das aspas dentro de
 aspas, alguém pode dar uma ajuda.

 Aqui está o código, e o problema com as aspas esta no primeiro e no
 terceiro EXECUTE:

 CREATE OR REPLACE FUNCTION wosis.fun_create_sequence(sch text)
   RETURNS text AS
 $BODY$
 DECLARE
 row record;
 BEGIN
 EXECUTE '  CREATE TEMP TABLE tmp AS
SELECT table_name, table_name||_id' AS id_name, 0 AS
 next_value
FROM information_schema.tables
WHERE table_schema = sch
AND  table_type = 'BASE TABLE'
ORDER BY table_name;';
 FOR row IN
  SELECT table_name, id_name FROM tmp ORDER BY table_name
 LOOP
 EXECUTE 'UPDATE tmp SET next_value = (SELECT max(' ||
 quote_ident(row.id_name) || ')+1 FROM ' || quote_ident(sch) || '.' ||
 quote_ident(row.table_name) || ') WHERE table_name = ' ||
 quote_ident(row.table_name) || ';'
 END LOOP;
 FOR row IN
  SELECT table_name, id_name, next_value FROM tmp ORDER BY table_name
 LOOP
 EXECUTE 'CREATE SEQUENCE ' || quote_ident(row.table_name) || '_'
 || quote_ident(row.id_name) || '_seq START ' || quote_ident(row.next_value)
 || ';'
 EXECUTE 'ALTER TABLE ' || quote_ident(sch) || '.' ||
 quote_ident(row.table_name) || ' ALTER COLUMN ' || quote_ident(row.id_name)
 || ' SET DEFAULT nextval( ' || quote_ident(row.table_name) || '_' ||
 quote_ident(row.id_name) || '_seq);'
 END LOOP;
 RETURN 'Sequences were created';
 END;
 $BODY$
   LANGUAGE plpgsql VOLATILE
   COST 100;
 ALTER FUNCTION wosis.fun_create_sequence(text) OWNER TO postgres;
 COMMENT ON FUNCTION wosis.fun_create_sequence(text) IS 'Create sequences
 in all tables from a given schema';

 Obrigado,

 --
 Eloi Ribeiro
 GIS Analyst / Programmer
 51.9871, 5.6661
 flavors.me/eloiribeiro
 ___
 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] duvida com as aspas dentro de aspas ao criar função

[Anderson Abreu]

Caríssimo,

Utilize duas aspas simples juntas tipo 'select ' '' '|| nome||' '' ' from
pessoa'






Atenciosamente,

Anderson Abreu
andersonab...@gmail.com
(61) 8157-6657
OOAD, RUP, SOA, Jboss, IIS
.Net, PHP, CFM, ASP, JAVA
McAffee Partner - Microsoft Partner
MySQL, Oracle, PostgreSQL, SQL Server, DB2, SyBase


2014/1/17 Eloi Ribeiro e...@openmailbox.org

 Ola a todos,

 Estou a tentar criar uma função que crie sequencias em todas as tabelas
 num determinado esquema e não consigo avançar por causa das aspas dentro de
 aspas, alguém pode dar uma ajuda.

 Aqui está o código, e o problema com as aspas esta no primeiro e no
 terceiro EXECUTE:

 CREATE OR REPLACE FUNCTION wosis.fun_create_sequence(sch text)
   RETURNS text AS
 $BODY$
 DECLARE
 row record;
 BEGIN
 EXECUTE '  CREATE TEMP TABLE tmp AS
SELECT table_name, table_name||_id' AS id_name, 0 AS
 next_value
FROM information_schema.tables
WHERE table_schema = sch
AND  table_type = 'BASE TABLE'
ORDER BY table_name;';
 FOR row IN
  SELECT table_name, id_name FROM tmp ORDER BY table_name
 LOOP
 EXECUTE 'UPDATE tmp SET next_value = (SELECT max(' ||
 quote_ident(row.id_name) || ')+1 FROM ' || quote_ident(sch) || '.' ||
 quote_ident(row.table_name) || ') WHERE table_name = ' ||
 quote_ident(row.table_name) || ';'
 END LOOP;
 FOR row IN
  SELECT table_name, id_name, next_value FROM tmp ORDER BY table_name
 LOOP
 EXECUTE 'CREATE SEQUENCE ' || quote_ident(row.table_name) || '_'
 || quote_ident(row.id_name) || '_seq START ' || quote_ident(row.next_value)
 || ';'
 EXECUTE 'ALTER TABLE ' || quote_ident(sch) || '.' ||
 quote_ident(row.table_name) || ' ALTER COLUMN ' || quote_ident(row.id_name)
 || ' SET DEFAULT nextval( ' || quote_ident(row.table_name) || '_' ||
 quote_ident(row.id_name) || '_seq);'
 END LOOP;
 RETURN 'Sequences were created';
 END;
 $BODY$
   LANGUAGE plpgsql VOLATILE
   COST 100;
 ALTER FUNCTION wosis.fun_create_sequence(text) OWNER TO postgres;
 COMMENT ON FUNCTION wosis.fun_create_sequence(text) IS 'Create sequences
 in all tables from a given schema';

 Obrigado,

 --
 Eloi Ribeiro
 GIS Analyst / Programmer
 51.9871, 5.6661
 flavors.me/eloiribeiro
 ___
 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] duvida com as aspas dentro de aspas ao criar função

[Heloisa Fernanda]

Use: EXECUTE $qualquercoisa$SELECT $qualquercoisa$||_variavel||$qualquercoisa$ 
FROM TABELA$qualquercoisa$;

Um detalhe: esse exemplo não funcionaria por que não dá para usar EXECUTE com 
SELECT.

Isso funcionaria: EXECUTE $qualquercoisa$UPDATE TABELA SET 
CAMPO=$qualquercoisa$||_VARIAVEL||$qualquercoisa$ WHERE 
OUTROCAMPO=1$qualquercoisa$;

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

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Flavio Henrique Araque Gurgel]

Um detalhe: esse exemplo não funcionaria por que não dá para usar
EXECUTE com SELECT.


Use PERFORM quando precisar gerar consulta dinâmica que retorne 
resultados, como SELECT.


[]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] duvida com as aspas dentro de aspas ao criar função

[Rafael Fialho Corrêa]

Em 17 de janeiro de 2014 14:18, Heloisa Fernanda
helois...@yahoo.com.brescreveu:


 Use: EXECUTE $qualquercoisa$SELECT $qualquercoisa$||_variavel||$qualquercoisa$
 FROM TABELA$qualquercoisa$;

 Um detalhe: esse exemplo não funcionaria por que não dá para usar EXECUTE
 com SELECT.


Isto é um equívoco.. Hehehe

É possível sim uma instrução select no execute, inclusive realizando um
execute select into variável, porém o problema neste caso é simplesmente
o execute de um comando pra criação de uma tabela. O problema está na
formatação da string que será executada.

Pro caso que está tentando utilizar, eu recomendaria um loop que retorne as
tabelas e/ou nomes, pra depois realizar a montagem do comando, assim fica
mais fácil de perceber o que está errado para poder consertar.

Poderia dar mais detalhes de qual é a intenção? De repente fica mais fácil
chegar a uma solução. Eu, particularmente, não entendi muito bem o objetivo
do todo.

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

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Flavio Henrique Araque Gurgel]

Um detalhe: esse exemplo não funcionaria por que não dá para usar
EXECUTE com SELECT.


Use PERFORM quando precisar gerar consulta dinâmica que retorne
resultados, como SELECT.


Eu só esqueci de acrescentar que os resultados serão *descartados* pelo 
perform. A utilidade dele é justamente essa, por exemplo, executar uma 
função, um SELECT...INTO, etc.


[]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] duvida com as aspas dentro de aspas ao criar função

[Matheus de Oliveira]

2014/1/17 Flavio Henrique Araque Gurgel fha...@gmail.com

  Um detalhe: esse exemplo não funcionaria por que não dá para usar
 EXECUTE com SELECT.


 Use PERFORM quando precisar gerar consulta dinâmica que retorne
 resultados, como SELECT.


 Eu só esqueci de acrescentar que os resultados serão *descartados* pelo
 perform. A utilidade dele é justamente essa, por exemplo, executar uma
 função, um SELECT...INTO, etc.


Acho que há uma confusão dos colegas nas três afirmações acima... Vou
resumir tudo abaixo para tentar esclarecer.

1. EXECUTE com SELECT é possível sim, por exemplo:

a) uma única linha:

EXECUTE 'SELECT ...' INTO minha_variavel;

b) várias linhas:

FOR variavel_record IN EXECUTE 'SELECT ...' LOOP
-- usar variavel_record.coluna1, ...
END LOOP;

2. O comando PERFORM não serve para executar consultas dinâmicas, apenas
para consultas estáticas (ou seja, não contidas numa variável ou
expressão). Consultas dinâmicas, ignorando ou não o resultado, sempre deve
ser usado o EXECUTE. É um erro que tenho visto bastante ultimamente, não
sei o porquê.

3. De fato o PERFORM descarta o valor. A palavra PERFORM deve ser usado
**exatamente** no lugar de onde estaria um SELECT, mas o resultado desse
SELECT deve ser descartado.

Para exemplificar um PERFORM, se você que chamar a função setval, via SQL
direto poderia simplesmente usar:

SELECT setval(...);

Via PL/pgSQL, também pode usar a forma acima, mas precisa
**obrigatoriamente** salvar o resultado numa variável:

SELECT setval(...) INTO variavel;

Agora, se quiser ignorar o resultado (ou seja, não salvar o valor na
variável), basta usar o mesmo modelo de SQL mas trocando a palavra SELECT
por PERFORM (que só é válido em PL/pgSQL, não SQL puro):

PERFORM setval(...);

Espero que tenha esclarecido (e não confundido mais, :P ).

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Matheus de Oliveira]

On Fri, Jan 17, 2014 at 11:54 AM, Eloi Ribeiro e...@openmailbox.org wrote:

 Ola a todos,

 Estou a tentar criar uma função que crie sequencias em todas as tabelas
 num determinado esquema e não consigo avançar por causa das aspas dentro de
 aspas, alguém pode dar uma ajuda.

 Aqui está o código, e o problema com as aspas esta no primeiro e no
 terceiro EXECUTE:

 CREATE OR REPLACE FUNCTION wosis.fun_create_sequence(sch text)
   RETURNS text AS
 $BODY$
 DECLARE
 row record;
 BEGIN
 EXECUTE '  CREATE TEMP TABLE tmp AS
SELECT table_name, table_name||_id' AS id_name, 0 AS
 next_value
FROM information_schema.tables
WHERE table_schema = sch
AND  table_type = 'BASE TABLE'
ORDER BY table_name;';
 FOR row IN
  SELECT table_name, id_name FROM tmp ORDER BY table_name
 LOOP
 EXECUTE 'UPDATE tmp SET next_value = (SELECT max(' ||
 quote_ident(row.id_name) || ')+1 FROM ' || quote_ident(sch) || '.' ||
 quote_ident(row.table_name) || ') WHERE table_name = ' ||
 quote_ident(row.table_name) || ';'
 END LOOP;
 FOR row IN
  SELECT table_name, id_name, next_value FROM tmp ORDER BY table_name
 LOOP
 EXECUTE 'CREATE SEQUENCE ' || quote_ident(row.table_name) || '_'
 || quote_ident(row.id_name) || '_seq START ' || quote_ident(row.next_value)
 || ';'
 EXECUTE 'ALTER TABLE ' || quote_ident(sch) || '.' ||
 quote_ident(row.table_name) || ' ALTER COLUMN ' || quote_ident(row.id_name)
 || ' SET DEFAULT nextval( ' || quote_ident(row.table_name) || '_' ||
 quote_ident(row.id_name) || '_seq);'
 END LOOP;
 RETURN 'Sequences were created';
 END;
 $BODY$
   LANGUAGE plpgsql VOLATILE
   COST 100;
 ALTER FUNCTION wosis.fun_create_sequence(text) OWNER TO postgres;
 COMMENT ON FUNCTION wosis.fun_create_sequence(text) IS 'Create sequences
 in all tables from a given schema';


É, parece que você criou uma bagunça com as aspas mesmo... Acho que vai
ficar mais fácil refazer a função do que ajustar cada problema nela. Já que
vamos refazer, que tal adicionar algumas dicas de ouro? ;-)


Bom, primeiro, veja o modelo que criei (não testei, então pode ter algum
erro que eu não tenha visto):

CREATE OR REPLACE FUNCTION wosis.fun_create_sequence(sch text)
RETURNS text
LANGUAGE plpgsql VOLATILE
AS
$BODY$
DECLARE
row record;
BEGIN
FOR row IN
SELECT table_name, table_name||'_id' AS id_name, 0 AS next_value
FROM information_schema.tables
WHERE table_schema = sch
AND  table_type = 'BASE TABLE'
ORDER BY table_name
LOOP
EXECUTE
format('SELECT max(%I)+1 FROM %I.%I', row.id_name, sch,
row.table_name)
INTO row.next_value;
EXECUTE
format(
'CREATE SEQUENCE %I.%I START %L OWNED BY %I.%I.%I;',
sch,
row.table_name||'_'||row.id_name||'_seq',
sch,
row.table_name,
row.id_name
);
   EXECUTE
   format(
'ALTER TABLE %I.%I ALTER COLUMN %I SET DEFAULT
nextval(%L);'
sch,
row.table_name,
row.id_name,
row.table_name||'_'||row.id_name||'_seq'
);
END LOOP;
RETURN 'Sequences were created';
END;
$BODY$;

Agora vejamos... Em primeiro lugar eu não usei uma tabela temporário,
simplesmente porque não vi sentido, e acho que acabou deixando a função
mais confusa ainda. Ao invés disso eu apenas naveguei no resultado da
consulta à view information_schema.tables. Repare também que não usei
consulta dinâmica (comando EXECUTE) nesta consulta, simplesmente porque não
é necessário e recomendo evitar o uso de EXECUTE ao máximo.

Em segundo lugar, precisamos de três comandos, um para fazer um `SELECT
max` para recuperar o maior valor, outro para criar a sequência e o último
para alterar o DEFAULT da tabela. Em ambos os casos a função format ajuda
bastante, e não precisa de tantos quote_ident's, que podem ser confusos.

Em [1] há um comparativo legal entre format e quote_ident. Veja lá e poste
dúvidas que sobrarem aqui.

Por fim, adicionei a cláusula OWNED BY no CREATE SEQUENCE, para deixar
idêntico ao que o pseudo-tipo SERIAL faz, e é uma boa prática para futuras
manutenções.

Só tenho mais um comentário. Esses comandos estão (talvez erroneamente)
assumindo que toda tabela tem um campo nome da tabela_id, mas talvez
faça parte do seu modelo, mas eu evitaria isso, a não ser que seja algo
executado somente numa tarefa administrativa.

Ufa... Leia com calma, tentei ser o mais claro possível. ^^

[1]
http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-QUOTE-LITERAL-EXAMPLE


Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - 

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Rafael Fialho Corrêa]

Em 17 de janeiro de 2014 21:22, Matheus de Oliveira 
matioli.math...@gmail.com escreveu:




 On Fri, Jan 17, 2014 at 11:54 AM, Eloi Ribeiro e...@openmailbox.orgwrote:

 Ola a todos,

 Estou a tentar criar uma função que crie sequencias em todas as tabelas
 num determinado esquema e não consigo avançar por causa das aspas dentro de
 aspas, alguém pode dar uma ajuda.

 Aqui está o código, e o problema com as aspas esta no primeiro e no
 terceiro EXECUTE:

 CREATE OR REPLACE FUNCTION wosis.fun_create_sequence(sch text)
   RETURNS text AS
 $BODY$
 DECLARE
 row record;
 BEGIN
 EXECUTE '  CREATE TEMP TABLE tmp AS
SELECT table_name, table_name||_id' AS id_name, 0 AS
 next_value
FROM information_schema.tables
WHERE table_schema = sch
AND  table_type = 'BASE TABLE'
ORDER BY table_name;';
 FOR row IN
  SELECT table_name, id_name FROM tmp ORDER BY table_name
 LOOP
 EXECUTE 'UPDATE tmp SET next_value = (SELECT max(' ||
 quote_ident(row.id_name) || ')+1 FROM ' || quote_ident(sch) || '.' ||
 quote_ident(row.table_name) || ') WHERE table_name = ' ||
 quote_ident(row.table_name) || ';'
 END LOOP;
 FOR row IN
  SELECT table_name, id_name, next_value FROM tmp ORDER BY table_name
 LOOP
 EXECUTE 'CREATE SEQUENCE ' || quote_ident(row.table_name) || '_'
 || quote_ident(row.id_name) || '_seq START ' || quote_ident(row.next_value)
 || ';'
 EXECUTE 'ALTER TABLE ' || quote_ident(sch) || '.' ||
 quote_ident(row.table_name) || ' ALTER COLUMN ' || quote_ident(row.id_name)
 || ' SET DEFAULT nextval( ' || quote_ident(row.table_name) || '_' ||
 quote_ident(row.id_name) || '_seq);'
 END LOOP;
 RETURN 'Sequences were created';
 END;
 $BODY$
   LANGUAGE plpgsql VOLATILE
   COST 100;
 ALTER FUNCTION wosis.fun_create_sequence(text) OWNER TO postgres;
 COMMENT ON FUNCTION wosis.fun_create_sequence(text) IS 'Create sequences
 in all tables from a given schema';


 É, parece que você criou uma bagunça com as aspas mesmo... Acho que vai
 ficar mais fácil refazer a função do que ajustar cada problema nela. Já que
 vamos refazer, que tal adicionar algumas dicas de ouro? ;-)


 Bom, primeiro, veja o modelo que criei (não testei, então pode ter algum
 erro que eu não tenha visto):

 CREATE OR REPLACE FUNCTION wosis.fun_create_sequence(sch text)
 RETURNS text
 LANGUAGE plpgsql VOLATILE
 AS
 $BODY$
 DECLARE
 row record;
 BEGIN
 FOR row IN
 SELECT table_name, table_name||'_id' AS id_name, 0 AS
 next_value
 FROM information_schema.tables
 WHERE table_schema = sch
 AND  table_type = 'BASE TABLE'
 ORDER BY table_name
 LOOP
 EXECUTE
 format('SELECT max(%I)+1 FROM %I.%I', row.id_name, sch,
 row.table_name)
 INTO row.next_value;
 EXECUTE
 format(
 'CREATE SEQUENCE %I.%I START %L OWNED BY %I.%I.%I;',
 sch,
 row.table_name||'_'||row.id_name||'_seq',
 sch,
 row.table_name,
 row.id_name
 );
EXECUTE
format(
 'ALTER TABLE %I.%I ALTER COLUMN %I SET DEFAULT
 nextval(%L);'
 sch,
 row.table_name,
 row.id_name,
 row.table_name||'_'||row.id_name||'_seq'
 );
 END LOOP;
 RETURN 'Sequences were created';
 END;
 $BODY$;

 Agora vejamos... Em primeiro lugar eu não usei uma tabela temporário,
 simplesmente porque não vi sentido, e acho que acabou deixando a função
 mais confusa ainda. Ao invés disso eu apenas naveguei no resultado da
 consulta à view information_schema.tables. Repare também que não usei
 consulta dinâmica (comando EXECUTE) nesta consulta, simplesmente porque não
 é necessário e recomendo evitar o uso de EXECUTE ao máximo.

 Em segundo lugar, precisamos de três comandos, um para fazer um `SELECT
 max` para recuperar o maior valor, outro para criar a sequência e o último
 para alterar o DEFAULT da tabela. Em ambos os casos a função format ajuda
 bastante, e não precisa de tantos quote_ident's, que podem ser confusos.

 Em [1] há um comparativo legal entre format e quote_ident. Veja lá e poste
 dúvidas que sobrarem aqui.

 Por fim, adicionei a cláusula OWNED BY no CREATE SEQUENCE, para deixar
 idêntico ao que o pseudo-tipo SERIAL faz, e é uma boa prática para futuras
 manutenções.

 Só tenho mais um comentário. Esses comandos estão (talvez erroneamente)
 assumindo que toda tabela tem um campo nome da tabela_id, mas talvez
 faça parte do seu modelo, mas eu evitaria isso, a não ser que seja algo
 executado somente numa tarefa administrativa.

 Ufa... Leia com calma, tentei ser o mais claro possível. ^^

 [1]
 

Re: [pgbr-geral] duvida com as aspas dentro de aspas ao criar função

[Matheus de Oliveira]

2014/1/17 Rafael Fialho Corrêa r.fia...@ibest.com.br

 Em 17 de janeiro de 2014 21:22, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:

 (...)


 Boa Matheus, bom saber que penso da mesma forma que os veteranos da
 lista.. hehehe
 Ia explicar da mesma forma, mas não tive tempo e o assunto ficou bem
 confuso.


Valeu cara. Sua explicação ficou boa sim, eu só achei que valia a pena
sumarizar tudo e explicar mais detalhadamente, pois a coisa estava ficando
meio confusa mesmo.

Quanto ao tempo, as vezes baixa um Chico Xavier em mim e digito um monte de
coisa num tapa só, =P.

Eu não me consideraria um veterano da lista, mas fico feliz pelo elogio.
:)

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida sobre sequence

[Matheus de Oliveira]

2013/12/15 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org

 2013/12/15 Wellington wm...@yahoo.com.br:
 
  tenho uma duvida: Eh possivel fazer uma consulta das sequencias que nao
  estao sendo utilizadas em nenhuma tabela ?

 Sim, pelo catálogo, como sempre.  Pense MINUS.




Exatamente. Se quisermos verificar as sequências que não estão no valor
padrão (default) de um atributo, podemos relacionar a pg_class para
recuperar todas as sequências (são aquelas cujo atributo relkind = 'S') com
a tabela pg_attrdef que possui o padrão de um campo (atributo adsrc). Por
exemplo:

SELECT r.oid::regclass
FROM pg_class r LEFT JOIN pg_attrdef d ON d.adsrc LIKE
'%'||(r.oid::regclass::text)||'%'
WHERE r.relkind = 'S' AND d.oid IS NULL;

Ao menos que use nomes estranhos em suas sequências, esta consulta
funcionará perfeitamente.



   Pelo que percebi, ao excluir uma tabela, a sequencia associada a ela
 nao é
  excluida.

 Porque não há associação de fato.  Uma seqüência pode servir várias
 tabelas, ou nenhuma.


Bem, não é **exatamente** assim. Por exemplo, quando cria-se uma sequência
utilizando o pseudo-tipo serial, o PostgreSQL irá sim associar a sequência
a uma tabela (na verdade ao atributo da tabela, e somente a um). Vejam o
exemplo:

postgres=# CREATE TABLE seq_test(a serial);
CREATE TABLE
== a sequência foi *criada* implicitamente
postgres=# SELECT nextval('seq_test_a_seq');
 nextval
-
   1
(1 row)

postgres=# DROP TABLE seq_test;
DROP TABLE
== a sequência foi *excluída* implicitamente
postgres=# SELECT nextval('seq_test_a_seq');
ERROR:  relation seq_test_a_seq does not exist
LINE 1: SELECT nextval('seq_test_a_seq');

Essa associação é feita usando o OWNED BY nos comandos CREATE/ALTER
SEQUENCE. Por exemplo, o código acima é exatamente equivalente a:

CREATE SEQUENCE seq_test_a_seq;
CREATE TABLE seq_test(a integer not null default
nextval('seq_test_a_seq'));
ALTER SEQUENCE seq_test_a_seq OWNED BY seq_test.a;

Com isso, a sequência passa a estar associada à tabela seq_test e
atributo a.

A vantagem é que, além de uma deleção da tabela também remover a sequência,
podemos forçar o TRUNCATE a zerar a sequência:

TRUNCATE seq_test RESTART IDENTITY;

Houve uma discussão sobre isso ano passado, e cheguei a criar uma consulta
para pegar as sequências e suas associações [1]. A mesma pode ser adaptada
para recuperar as sequências que não estão associadas a nenhum atributo (em
geral elas deveriam, mas não é uma regra):

SELECT s.oid::regclass AS sequence
FROM pg_class s
LEFT JOIN pg_depend d ON s.oid = d.objid AND d.deptype = 'a'
 LEFT JOIN pg_class t ON d.refobjid = t.oid
 LEFT JOIN pg_attribute a ON a.attrelid = t.oid AND a.attnum =
d.refobjsubid
WHERE s.relkind = 'S' AND t.oid IS NULL;


[1]
http://listas.postgresql.org.br/pipermail/pgbr-geral/2012-August/031827.html

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida sobre sequence

[Guimarães Faria Corcete DUTRA , Leandro]

2013/12/16 Matheus de Oliveira matioli.math...@gmail.com:

 Porque não há associação de fato.  Uma seqüência pode servir várias
 tabelas, ou nenhuma.

 Bem, não é **exatamente** assim. Por exemplo, quando cria-se uma sequência
 utilizando o pseudo-tipo serial, o PostgreSQL irá sim associar a sequência a
 uma tabela (na verdade ao atributo da tabela, e somente a um).

Isso é que dá ficar desatualizado… obrigado!



 Essa associação é feita usando o OWNED BY nos comandos CREATE/ALTER
 SEQUENCE.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida sobre sequence

[Guimarães Faria Corcete DUTRA , Leandro]

2013/12/15 Wellington wm...@yahoo.com.br:

 tenho uma duvida: Eh possivel fazer uma consulta das sequencias que nao
 estao sendo utilizadas em nenhuma tabela ?

Sim, pelo catálogo, como sempre.  Pense MINUS.


 Pelo que percebi, ao excluir uma tabela, a sequencia associada a ela nao é
 excluida.

Porque não há associação de fato.  Uma seqüência pode servir várias
tabelas, ou nenhuma.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Duvida sobre sequence

[Wellington]

Pessoal,

tenho uma duvida: Eh possivel fazer uma consulta das sequencias que nao 
estao sendo utilizadas em nenhuma tabela ?


Pelo que percebi, ao excluir uma tabela, a sequencia associada a ela nao é 
excluida.



Desde ja, agradeco.
Wellington 


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

Re: [pgbr-geral] Duvida em dump

[Tiago Daniel Jacobs]

Rogério, você pode fazer um dump apenas da estrutura. E outro com os dados. No 
dump de dados rode com a opcao de gerar comandos de insert. Feito isso use o 
grep para separar as linhas com o codigo desejado

Enviado via iPhone

 Em Oct 7, 2013, às 4:27 PM, Rogério Grando rogeriogra...@planin.com.br 
 escreveu:
 
 Olá pessoal, boa tarde!
  
 Tenho uma base de dados que armazena várias empresa, sendo dividido por uma 
 coluna co_empresa em todas as tabelas.
 Preciso fazer um backup apenas de uma empresa.
 Sei que com dump não é possível, por não ter clausula WHERE. “Que bom seria.”
 Alguém já precisou fazer isso?
 Versão: Postgres 8.3.20 em Linux: Debian
  
 Outro problema, já a algum tempo não estou recebendo os e-mails da lista, é 
 necessário recadastrar?
  
 Grato, pela habitual atenção de todos.
 ___
 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] Duvida em dump

[Rogério Grando]

Olá pessoal, boa tarde!

Tenho uma base de dados que armazena várias empresa, sendo dividido por uma 
coluna co_empresa em todas as tabelas.
Preciso fazer um backup apenas de uma empresa.
Sei que com dump não é possível, por não ter clausula WHERE. “Que bom seria.”
Alguém já precisou fazer isso?
Versão: Postgres 8.3.20 em Linux: Debian

Outro problema, já a algum tempo não estou recebendo os e-mails da lista, é 
necessário recadastrar? 

Grato, pela habitual atenção de 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] Duvida em dump

[Osvaldo Kussama]

Em 07/10/13, Rogério Grandorogeriogra...@planin.com.br escreveu:
 Olá pessoal, boa tarde!

 Tenho uma base de dados que armazena várias empresa, sendo dividido por uma
 coluna co_empresa em todas as tabelas.
 Preciso fazer um backup apenas de uma empresa.
 Sei que com dump não é possível, por não ter clausula WHERE. “Que bom
 seria.”
 Alguém já precisou fazer isso?
 Versão: Postgres 8.3.20 em Linux: Debian

 Outro problema, já a algum tempo não estou recebendo os e-mails da lista, é
 necessário recadastrar?



Você está ciente de que a versão 8.3 deixou de ser suportada em Fevereiro/2013?

Existem diversos relatos de que as mensagens da lista estão sendo
consideradas spam. Verifique sua caixa de spam.

Trate o arquivo gerado com o sed.

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] duvida de uma consulta

[Matheus de Oliveira]

2013/8/4 lucas . lucasouz...@hotmail.com

 Ola gente, tenho uma dúvida.

 Usando esta consulta

 SELECT *

 FROM Auth, Publ

 WHERE Auth.pubID = Publ.pubID AND Auth.nome = 'Surajit Chaudhuri'



 índices primários sobre Auth.pubID e Publ.pubID e índice secundário sobre
 Auth.nome.


 O algoritmo escolhido pelo postgre sera o Nested loop. Entendo que ele faz
 esta escolha pelo fato da seleção ser feita antes da junção dessa forma o
 desempenho da junção será melhor com o nested. Confirma?



Em geral, o PostgreSQL tende a usar o nested loop quando está trabalhando
com um conjunto pequeno de dados (pelo menos dos vindos da tabela da
direita), mas veja que a definição de pequeno vai depender dos custos
definidos. Nesse caso o filtro em Auth.nome pode sim explicar essa
escolha. Poste o resultado do seguinte comando para te darmos uma resposta
mais certeira:

ANALYZE Auth;
ANALYZE Publ;
EXPLAIN ANALYZE SELECT *
FROM Auth, Publ
WHERE Auth.pubID = Publ.pubID AND Auth.nome = 'Surajit Chaudhuri'



  E outra dúvida, no pgadmin aonde que eu posso olhar a PEC da consulta?


PEC seria o quê? Plano de execução? Acho que ele tem um botão para executar
e mostrar, mas você também pode usar o EXPLAIN (como acima).


Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida de uma consulta

[Matheus de Oliveira]

2013/8/4 lucas . lucasouz...@hotmail.com

 do postgre

 E eu estou enviando pelo meu email as respostas acho que por isto esta
 bagunçando a lista. Poderia me enviar o link da lista? ja perdi


Pode enviar por e-mail mesmo, mas edite a resposta colocando sua abaixo da
resposta do anterior. Como estou fazendo aqui.

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] duvida de uma consulta

[lucas .]

Ola gente, tenho uma dúvida.

Usando esta consulta

SELECT *FROM Auth, PublWHERE Auth.pubID = Publ.pubID AND Auth.nome = 'Surajit 
Chaudhuri'

índices primários sobre Auth.pubID e Publ.pubID e índice secundário sobre 
Auth.nome.
O algoritmo escolhido pelo postgre sera o Nested loop. Entendo que ele faz esta 
escolha pelo fato da seleção ser feita antes da junção dessa forma o desempenho 
da junção será melhor com o nested. Confirma?
E outra dúvida, no pgadmin aonde que eu posso olhar a PEC da consulta?


Att,Lucas José Duarte de SouzaBacharelando em Ciência da ComputaçãoUniversidade 
Federal de Lavras.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida de uma consulta

[Osvaldo Kussama]

Em 04/08/13, lucas .lucasouz...@hotmail.com escreveu:
 Ola gente, tenho uma dúvida.

 Usando esta consulta

 SELECT *FROM Auth, PublWHERE Auth.pubID = Publ.pubID AND Auth.nome =
 'Surajit Chaudhuri'

 índices primários sobre Auth.pubID e Publ.pubID e índice secundário sobre
 Auth.nome.
 O algoritmo escolhido pelo postgre sera o Nested loop. Entendo que ele faz
 esta escolha pelo fato da seleção ser feita antes da junção dessa forma o
 desempenho da junção será melhor com o nested. Confirma?
 E outra dúvida, no pgadmin aonde que eu posso olhar a PEC da consulta?



Para saber o plano de execução da consulta rode um EXPLAIN [1].
Certifique-se de que as estatísticas de seu banco estejam atualizadas
(rode um ANALYZE [2]).

Não é o simples fato de existir um índice que fará com que seu uso
seja considerado a solução mais econômica.

Se desejar forçar a junção faça:
SELECT * FROM
Auth INNER JOIN Publ ON(Auth.pubID = Publ.pubID)
WHERE Auth.nome = 'Surajit Chaudhuri';

Osvaldo

[1] http://www.postgresql.org/docs/current/interactive/sql-explain.html
[2] http://www.postgresql.org/docs/current/interactive/sql-analyze.html
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida de uma consulta

[lucas .]

Então não estou julgando que seja pelo indice. Estou dizendo que pelo PEC a 
seleção é feita primeiro diminuindo o numero de junções possiveis. Dessa forma, 
o nested loop é uma escolha melhor

Att,Lucas José Duarte de SouzaBacharelando em Ciência da ComputaçãoUniversidade 
Federal de Lavras.

 Date: Sun, 4 Aug 2013 19:30:27 -0300
 From: osvaldo.kuss...@gmail.com
 To: pgbr-geral@listas.postgresql.org.br
 Subject: Re: [pgbr-geral] duvida de uma consulta
 
 Em 04/08/13, lucas .lucasouz...@hotmail.com escreveu:
  Ola gente, tenho uma dúvida.
 
  Usando esta consulta
 
  SELECT *FROM Auth, PublWHERE Auth.pubID = Publ.pubID AND Auth.nome =
  'Surajit Chaudhuri'
 
  índices primários sobre Auth.pubID e Publ.pubID e índice secundário sobre
  Auth.nome.
  O algoritmo escolhido pelo postgre sera o Nested loop. Entendo que ele faz
  esta escolha pelo fato da seleção ser feita antes da junção dessa forma o
  desempenho da junção será melhor com o nested. Confirma?
  E outra dúvida, no pgadmin aonde que eu posso olhar a PEC da consulta?
 
 
 
 Para saber o plano de execução da consulta rode um EXPLAIN [1].
 Certifique-se de que as estatísticas de seu banco estejam atualizadas
 (rode um ANALYZE [2]).
 
 Não é o simples fato de existir um índice que fará com que seu uso
 seja considerado a solução mais econômica.
 
 Se desejar forçar a junção faça:
 SELECT * FROM
 Auth INNER JOIN Publ ON(Auth.pubID = Publ.pubID)
 WHERE Auth.nome = 'Surajit Chaudhuri';
 
 Osvaldo
 
 [1] http://www.postgresql.org/docs/current/interactive/sql-explain.html
 [2] http://www.postgresql.org/docs/current/interactive/sql-analyze.html
 ___
 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] duvida de uma consulta

[Osvaldo Kussama]

Em 04/08/13, lucas .lucasouz...@hotmail.com escreveu:
 Então não estou julgando que seja pelo indice. Estou dizendo que pelo PEC a
 seleção é feita primeiro diminuindo o numero de junções possiveis. Dessa
 forma, o nested loop é uma escolha melhor

 Att,Lucas José Duarte de SouzaBacharelando em Ciência da
 ComputaçãoUniversidade Federal de Lavras.

 Date: Sun, 4 Aug 2013 19:30:27 -0300
 From: osvaldo.kuss...@gmail.com
 To: pgbr-geral@listas.postgresql.org.br
 Subject: Re: [pgbr-geral] duvida de uma consulta

 Em 04/08/13, lucas .lucasouz...@hotmail.com escreveu:
  Ola gente, tenho uma dúvida.
 
  Usando esta consulta
 
  SELECT *FROM Auth, PublWHERE Auth.pubID = Publ.pubID AND Auth.nome =
  'Surajit Chaudhuri'
 
  índices primários sobre Auth.pubID e Publ.pubID e índice secundário
  sobre
  Auth.nome.
  O algoritmo escolhido pelo postgre sera o Nested loop. Entendo que ele
  faz
  esta escolha pelo fato da seleção ser feita antes da junção dessa forma
  o
  desempenho da junção será melhor com o nested. Confirma?
  E outra dúvida, no pgadmin aonde que eu posso olhar a PEC da consulta?
 


 Para saber o plano de execução da consulta rode um EXPLAIN [1].
 Certifique-se de que as estatísticas de seu banco estejam atualizadas
 (rode um ANALYZE [2]).

 Não é o simples fato de existir um índice que fará com que seu uso
 seja considerado a solução mais econômica.

 Se desejar forçar a junção faça:
 SELECT * FROM
 Auth INNER JOIN Publ ON(Auth.pubID = Publ.pubID)
 WHERE Auth.nome = 'Surajit Chaudhuri';

 Osvaldo

 [1] http://www.postgresql.org/docs/current/interactive/sql-explain.html
 [2] http://www.postgresql.org/docs/current/interactive/sql-analyze.html
 ___


Evite top-posting, você bagunça o histórico da lista.

Você está firmando que o plano de execução será este baseado na
análise do código do PostgreSQL ou em teoria?

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] duvida de uma consulta

[lucas .]

do postgre

E eu estou enviando pelo meu email as respostas acho que por isto esta 
bagunçando a lista. Poderia me enviar o link da lista? ja perdi

Att,Lucas José Duarte de SouzaBacharelando em Ciência da ComputaçãoUniversidade 
Federal de Lavras.

 Date: Sun, 4 Aug 2013 19:51:47 -0300
 From: osvaldo.kuss...@gmail.com
 To: pgbr-geral@listas.postgresql.org.br
 Subject: Re: [pgbr-geral] duvida de uma consulta
 
 Em 04/08/13, lucas .lucasouz...@hotmail.com escreveu:
  Então não estou julgando que seja pelo indice. Estou dizendo que pelo PEC a
  seleção é feita primeiro diminuindo o numero de junções possiveis. Dessa
  forma, o nested loop é uma escolha melhor
 
  Att,Lucas José Duarte de SouzaBacharelando em Ciência da
  ComputaçãoUniversidade Federal de Lavras.
 
  Date: Sun, 4 Aug 2013 19:30:27 -0300
  From: osvaldo.kuss...@gmail.com
  To: pgbr-geral@listas.postgresql.org.br
  Subject: Re: [pgbr-geral] duvida de uma consulta
 
  Em 04/08/13, lucas .lucasouz...@hotmail.com escreveu:
   Ola gente, tenho uma dúvida.
  
   Usando esta consulta
  
   SELECT *FROM Auth, PublWHERE Auth.pubID = Publ.pubID AND Auth.nome =
   'Surajit Chaudhuri'
  
   índices primários sobre Auth.pubID e Publ.pubID e índice secundário
   sobre
   Auth.nome.
   O algoritmo escolhido pelo postgre sera o Nested loop. Entendo que ele
   faz
   esta escolha pelo fato da seleção ser feita antes da junção dessa forma
   o
   desempenho da junção será melhor com o nested. Confirma?
   E outra dúvida, no pgadmin aonde que eu posso olhar a PEC da consulta?
  
 
 
  Para saber o plano de execução da consulta rode um EXPLAIN [1].
  Certifique-se de que as estatísticas de seu banco estejam atualizadas
  (rode um ANALYZE [2]).
 
  Não é o simples fato de existir um índice que fará com que seu uso
  seja considerado a solução mais econômica.
 
  Se desejar forçar a junção faça:
  SELECT * FROM
  Auth INNER JOIN Publ ON(Auth.pubID = Publ.pubID)
  WHERE Auth.nome = 'Surajit Chaudhuri';
 
  Osvaldo
 
  [1] http://www.postgresql.org/docs/current/interactive/sql-explain.html
  [2] http://www.postgresql.org/docs/current/interactive/sql-analyze.html
  ___
 
 
 Evite top-posting, você bagunça o histórico da lista.
 
 Você está firmando que o plano de execução será este baseado na
 análise do código do PostgreSQL ou em teoria?
 
 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

[pgbr-geral] duvida

[lucas .]

Ola galera. Sou novo por aqui, comecei usar o postgresql a pouco tempo e tenho 
uma dúvida. Qual é o comando para criar indices secundários?

Att,Lucas José Duarte de SouzaBacharelando em Ciência da ComputaçãoUniversidade 
Federal de Lavras.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida

[Fabrízio de Royes Mello]

2013/7/8 lucas . lucasouz...@hotmail.com

 Ola galera. Sou novo por aqui, comecei usar o postgresql a pouco tempo e
 tenho uma dúvida. Qual é o comando para criar indices secundários?


Índice secundário??? Vc não quis dizer Chave Secundária (ou Alternativa)
???
Se for este o caso vc define isso adicionando uma restrição do tipo UNIQUE
na
sua tabela, veja documentação [1] e [2]. Ex:

ALTER TABLE tabela ADD CONSTRAINT tabela_skey UNIQUE (campo_unico);

Att,

[1] http://www.postgresql.org/docs/current/interactive/sql-createtable.html
[2] http://www.postgresql.org/docs/current/interactive/sql-altertable.html

-- 
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Blog sobre TI: http://fabriziomello.blogspot.com
 Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida

[Bruno Silva]

2013/7/8 lucas . lucasouz...@hotmail.com

 Ola galera. Sou novo por aqui, comecei usar o postgresql a pouco tempo e
 tenho uma dúvida. Qual é o comando para criar indices secundários?


Se for só índices mesmo:
http://www.postgresql.org/docs/9.2/interactive/indexes.html

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] duvida

[lucas .]

Sim, mas no caso eu queria saber o comando especifico para criar indices 
secundários. Eu estava achando que era usando o UNIQUE.

Att,Lucas José Duarte de SouzaBacharelando em Ciência da ComputaçãoUniversidade 
Federal de Lavras.

From: bemanuel...@gmail.com
Date: Mon, 8 Jul 2013 10:34:06 -0300
To: pgbr-geral@listas.postgresql.org.br
Subject: Re: [pgbr-geral] duvida


2013/7/8 lucas . lucasouz...@hotmail.com


Ola galera. Sou novo por aqui, comecei usar o postgresql a pouco tempo e tenho 
uma dúvida. Qual é o comando para criar indices secundários?

Se for só índices 
mesmo:http://www.postgresql.org/docs/9.2/interactive/indexes.html

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] duvida

[lucas .]

Indice secundario que eu digo é que não determinam a organização do arquivo de 
dados indexado
Att,Lucas José Duarte de SouzaBacharelando em Ciência da ComputaçãoUniversidade 
Federal de Lavras.

From: lucasouz...@hotmail.com
To: pgbr-geral@listas.postgresql.org.br
Date: Mon, 8 Jul 2013 13:39:35 +
Subject: Re: [pgbr-geral] duvida




Sim, mas no caso eu queria saber o comando especifico para criar indices 
secundários. Eu estava achando que era usando o UNIQUE.

Att,Lucas José Duarte de SouzaBacharelando em Ciência da ComputaçãoUniversidade 
Federal de Lavras.

From: bemanuel...@gmail.com
Date: Mon, 8 Jul 2013 10:34:06 -0300
To: pgbr-geral@listas.postgresql.org.br
Subject: Re: [pgbr-geral] duvida


2013/7/8 lucas . lucasouz...@hotmail.com


Ola galera. Sou novo por aqui, comecei usar o postgresql a pouco tempo e tenho 
uma dúvida. Qual é o comando para criar indices secundários?

Se for só índices 
mesmo:http://www.postgresql.org/docs/9.2/interactive/indexes.html

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
  ___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida

[Flavio Henrique Araque Gurgel]

Em 08-07-2013 10:46, lucas . escreveu:

Indice secundario que eu digo é que não determinam a organização do
arquivo de dados indexado


Evite por favor o top-posting.

Você está falando de índice em tabela clusterizada, certo?

Isso não existe no PostgreSQL. Nenhum tipo de índice determina a 
organização do arquivo de dados.


Todavia, uma tabela pode ser organizada, por desejo do administrador, 
quando necessário através do comando CLUSTER.


Resumindo, o que você parece estar querendo é criar um índice comum. Use 
CREATE INDEX e feito.


[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida

[lucas .]

Acho que sim, seria isto, Flávio. Bom vou tirar esta duvida com meu professor, 
qualquer coisa volto aqui

Att,Lucas José Duarte de SouzaBacharelando em Ciência da ComputaçãoUniversidade 
Federal de Lavras.


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

[pgbr-geral] Duvida básica LEFT JOIN x NOT IN

[Marcelo da Silva]

Qual seria o mais eficiente ?

SELECT A.CAMPOS FROM TABELA_A A
LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
WHERE (B.CAMPO IS NULL)

ou

SELECT A.CAMPOS FROM TABEL_A A
WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))


-- 
Marcelo Silva

Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN

[Flavio Henrique Araque Gurgel]

Em 05-07-2013 14:25, Marcelo da Silva escreveu:

Qual seria o mais eficiente ?

SELECT A.CAMPOS FROM TABELA_A A
LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
WHERE (B.CAMPO IS NULL)

ou

SELECT A.CAMPOS FROM TABEL_A A
WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))


Depende do tamanho das tabelas, índices, distribuição de dados, etc.
EXPLAIN ANALYZE nelas e você saberá.

[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN

[Claudio Bezerra Leopoldino]

Não depende apenas da consulta. Depende dos dados armazenados e estatísticas no 
seu servidor.

Peço que use explain e noso envie o reultado:


EXPLAIN SELECT A.CAMPOS FROM TABELA_A A
LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
WHERE (B.CAMPO IS NULL)

e

EXPLAIN  SELECT A.CAMPOS FROM TABEL_A A

WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))

Cordialmente,


Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Marcelo da Silva marc...@ig.com.br
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br 
Enviadas: Sexta-feira, 5 de Julho de 2013 14:25
Assunto: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN
 


Qual seria o mais eficiente ?

SELECT A.CAMPOS FROM TABELA_A A
LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
WHERE (B.CAMPO IS NULL)

ou

SELECT A.CAMPOS FROM TABEL_A A

WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))

-- 

Marcelo Silva

Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251
___
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] Duvida básica LEFT JOIN x NOT IN

[Marcelo da Silva]

Tempo os seguintes resultados:

OPCAO A

explain select a.* from mv_servicos_balcao a
left join mv_servicos_print b on(cod_key_balcao = a.cod_key)
where (b.cod_key is null)
  and(a.obs not in('C'));

Hash Right Join  (cost=9510.11..17269.55 rows=1 width=136)
  Hash Cond: (b.cod_key_balcao = a.cod_key)
  Filter: (b.cod_key IS NULL)
  -  Seq Scan on mv_servicos_print b  (cost=0.00..3746.55 rows=213355
width=8)
  -  Hash  (cost=7913.20..7913.20 rows=127753 width=136)
-  Seq Scan on mv_servicos_balcao a  (cost=0.00..7913.20
rows=127753 width=136)
  Filter: (obs  'C'::bpchar)


OPCAO B

explain select a.* from mv_servicos_balcao a
where (a.obs not in('C'))
  and(a.cod_key not in(select cod_key_balcao from mv_servicos_print))

Seq Scan on mv_servicos_balcao a  (cost=4279.94..12516.98 rows=63876
width=136)
  Filter: ((obs  'C'::bpchar) AND (NOT (hashed SubPlan 1)))
  SubPlan 1
-  Seq Scan on mv_servicos_print  (cost=0.00..3746.55 rows=213355
width=4)


Vou ser sincero... não sei fazer a leitura do explain, mas pelo que vi a
segunda opção se mostrou mais eficiente, haja visto que sem o explain temos
os seguintes valores em ms(milisegundos)

OPCAO A = 571 rows e 496ms
OPCAO B = 571 rows e 300ms

Mito detonado ? rsrsrs



Em 5 de julho de 2013 14:31, Claudio Bezerra Leopoldino 
claudiob...@yahoo.com.br escreveu:

 Não depende apenas da consulta. Depende dos dados armazenados e
 estatísticas no seu servidor.

 Peço que use explain e noso envie o reultado:

 EXPLAIN SELECT A.CAMPOS FROM TABELA_A A
 LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
 WHERE (B.CAMPO IS NULL)

 e

 EXPLAIN  SELECT A.CAMPOS FROM TABEL_A A

 WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))

 Cordialmente,

 Cláudio Leopoldino
 postgresqlbr.blogspot.com/
 =
   --
  *De:* Marcelo da Silva marc...@ig.com.br
 *Para:* Comunidade PostgreSQL Brasileira 
 pgbr-geral@listas.postgresql.org.br
 *Enviadas:* Sexta-feira, 5 de Julho de 2013 14:25
 *Assunto:* [pgbr-geral] Duvida básica LEFT JOIN x NOT IN

 Qual seria o mais eficiente ?

 SELECT A.CAMPOS FROM TABELA_A A
 LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
 WHERE (B.CAMPO IS NULL)

 ou

 SELECT A.CAMPOS FROM TABEL_A A
 WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))


 --
 Marcelo Silva
 
 Desenvolvedor Delphi / PHP
 My Postgres database
 Cel.: (11) 99693-4251

 ___
 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




-- 
Marcelo Silva

Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN

[Flavio Henrique Araque Gurgel]

Em 05-07-2013 14:54, Marcelo da Silva escreveu:

Tempo os seguintes resultados:

OPCAO A

explain select a.* from mv_servicos_balcao a
left join mv_servicos_print b on(cod_key_balcao = a.cod_key)
where (b.cod_key is null)
   and(a.obs not in('C'));

Hash Right Join  (cost=9510.11..17269.55 rows=1 width=136)
  Hash Cond: (b.cod_key_balcao = a.cod_key)
  Filter: (b.cod_key IS NULL)
  -  Seq Scan on mv_servicos_print b  (cost=0.00..3746.55 rows=213355
width=8)
  -  Hash  (cost=7913.20..7913.20 rows=127753 width=136)
-  Seq Scan on mv_servicos_balcao a  (cost=0.00..7913.20
rows=127753 width=136)
  Filter: (obs  'C'::bpchar)


OPCAO B

explain select a.* from mv_servicos_balcao a
where (a.obs not in('C'))
   and(a.cod_key not in(select cod_key_balcao from mv_servicos_print))

Seq Scan on mv_servicos_balcao a  (cost=4279.94..12516.98 rows=63876
width=136)
  Filter: ((obs  'C'::bpchar) AND (NOT (hashed SubPlan 1)))
  SubPlan 1
-  Seq Scan on mv_servicos_print  (cost=0.00..3746.55 rows=213355
width=4)


Vou ser sincero... não sei fazer a leitura do explain, mas pelo que vi a
segunda opção se mostrou mais eficiente, haja visto que sem o explain
temos os seguintes valores em ms(milisegundos)

OPCAO A = 571 rows e 496ms
OPCAO B = 571 rows e 300ms

Mito detonado ? rsrsrs


Não só o tempo foi menor como o custo total da consulta também foi (4279 
versus 9510).


Logo, fique com a opção B.
Note que suas tabelas têm poucas linhas, nenhum índice foi utilizado. 
Considere criar índice (se já não houver) na coluna cod_key da tabela 
mv_servicos_balcao. Todavia, dependendo da quantidade de resultados 
dessa tabela em relação ao tamanho total dela, pode ser que o índice 
nunca seja utilizado. Crie-o (se já não houver) e teste novamente.


[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN

[Matheus de Oliveira]

2013/7/5 Marcelo da Silva marc...@ig.com.br

 Tempo os seguintes resultados:

 OPCAO A

 explain select a.* from mv_servicos_balcao a
 left join mv_servicos_print b on(cod_key_balcao = a.cod_key)
 where (b.cod_key is null)
   and(a.obs not in('C'));

 Hash Right Join  (cost=9510.11..17269.55 rows=1 width=136)
   Hash Cond: (b.cod_key_balcao = a.cod_key)
   Filter: (b.cod_key IS NULL)
   -  Seq Scan on mv_servicos_print b  (cost=0.00..3746.55 rows=213355
 width=8)
   -  Hash  (cost=7913.20..7913.20 rows=127753 width=136)
 -  Seq Scan on mv_servicos_balcao a  (cost=0.00..7913.20
 rows=127753 width=136)
   Filter: (obs  'C'::bpchar)


 OPCAO B

 explain select a.* from mv_servicos_balcao a
 where (a.obs not in('C'))
   and(a.cod_key not in(select cod_key_balcao from mv_servicos_print))

 Seq Scan on mv_servicos_balcao a  (cost=4279.94..12516.98 rows=63876
 width=136)
   Filter: ((obs  'C'::bpchar) AND (NOT (hashed SubPlan 1)))
SubPlan 1
 -  Seq Scan on mv_servicos_print  (cost=0.00..3746.55 rows=213355
 width=4)


 Vou ser sincero... não sei fazer a leitura do explain, mas pelo que vi a
 segunda opção se mostrou mais eficiente, haja visto que sem o explain temos
 os seguintes valores em ms(milisegundos)

 OPCAO A = 571 rows e 496ms
 OPCAO B = 571 rows e 300ms


Possível. Mas para termos mais certeza, faça o seguinte:

VACUUM ANALYZE  mv_servicos_balcao;
VACUUM ANALYZE mv_servicos_print;

Em seguida, rode novamente as queries, mas ao invés de apenas explain use:

EXPLAIN (ANALYZE, BUFFERS) SELECT ... ;

E rode pelo menos duas vezes cada para evitar efeitos de cache (o ideal
seria executar um restart, mas 2 execuções deve dar um bom retorno).


Mito detonado ? rsrsrs


Qual o mito afinal?

xD


Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN

[Claudio Bezerra Leopoldino]

Marcelo, a diferença de custos entre as duas opções não é tão significativa. 

Os planos de execução mostram que você está fazendo sequential scans. Neste 
caso, aconselho que tente indexar as colunas utilizadas nas junções e teste se 
há melhoria na sua consulta e depois disso peço que repita o teste do explain.

Cordialmente,


Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Marcelo da Silva marc...@ig.com.br
Para: Claudio Bezerra Leopoldino claudiob...@yahoo.com.br; Comunidade 
PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br 
Enviadas: Sexta-feira, 5 de Julho de 2013 14:54
Assunto: Re: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN
 


Tempo os seguintes resultados:

OPCAO A


explain select a.* from mv_servicos_balcao a
left join mv_servicos_print b on(cod_key_balcao = a.cod_key)
where (b.cod_key is null)
  and(a.obs not in('C'));

Hash Right Join  (cost=9510.11..17269.55 rows=1 width=136)
  Hash Cond: (b.cod_key_balcao = a.cod_key)
  Filter: (b.cod_key IS NULL)
  -  Seq Scan on mv_servicos_print b  (cost=0.00..3746.55 rows=213355 
width=8)
  -  Hash  (cost=7913.20..7913.20 rows=127753 width=136)
        -  Seq Scan on mv_servicos_balcao a  (cost=0.00..7913.20 rows=127753 
width=136)
              Filter: (obs  'C'::bpchar)


OPCAO B

explain select a.* from mv_servicos_balcao a
where (a.obs not in('C'))
  and(a.cod_key not in(select cod_key_balcao from mv_servicos_print))

Seq Scan on mv_servicos_balcao a  (cost=4279.94..12516.98 rows=63876 
width=136)
  Filter: ((obs  'C'::bpchar) AND (NOT (hashed SubPlan 1)))
  SubPlan 1
    -  Seq Scan on mv_servicos_print  (cost=0.00..3746.55 rows=213355 
width=4)


Vou ser sincero... não sei fazer a leitura do explain, mas pelo que vi a 
segunda opção se mostrou mais eficiente, haja visto que sem o explain temos os 
seguintes valores em ms(milisegundos)

OPCAO A = 571 rows e 496ms
OPCAO B = 571 rows e 300ms

Mito detonado ? rsrsrs




Em 5 de julho de 2013 14:31, Claudio Bezerra Leopoldino 
claudiob...@yahoo.com.br escreveu:

Não depende apenas da consulta. Depende dos dados armazenados e estatísticas no 
seu servidor.

Peço que use explain e noso envie o reultado:


EXPLAIN SELECT A.CAMPOS FROM TABELA_A A
LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
WHERE (B.CAMPO IS NULL)


e


EXPLAIN  SELECT A.CAMPOS FROM TABEL_A A


WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))


Cordialmente,


Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Marcelo da Silva marc...@ig.com.br
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br 
Enviadas: Sexta-feira, 5 de Julho de 2013 14:25
Assunto: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN
 


Qual seria o mais eficiente ?


SELECT A.CAMPOS FROM TABELA_A A
LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
WHERE (B.CAMPO IS NULL)


ou


SELECT A.CAMPOS FROM TABEL_A A

WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))



-- 

Marcelo Silva

Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251

___
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




-- 

Marcelo Silva

Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN

[Bruno Silva]

2013/7/5 Claudio Bezerra Leopoldino claudiob...@yahoo.com.br

 EXPLAIN  SELECT A.CAMPOS FROM TABEL_A A

 WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))


Trocaria o NOT IN port NOT EXISTS

Bruno E. A. Silva.
Analista de Sistemas.
Bacharel em Sistemas de Informação
Pós-graduando em Gerência de Projetos
Certified Scrum Master
LPIC-1
SCJP, SE 6
Novell CLA / DCTS ECR
DBA Postgres
---
“A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” -
Sábio Desconhecido
Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN

[Marcelo da Silva]

O NOT IN ainda está sendo o mais eficiente




Em 5 de julho de 2013 16:07, Bruno Silva bemanuel...@gmail.com escreveu:


 2013/7/5 Claudio Bezerra Leopoldino claudiob...@yahoo.com.br

 EXPLAIN  SELECT A.CAMPOS FROM TABEL_A A

 WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))


 Trocaria o NOT IN port NOT EXISTS

 Bruno E. A. Silva.
 Analista de Sistemas.
 Bacharel em Sistemas de Informação
 Pós-graduando em Gerência de Projetos
 Certified Scrum Master
 LPIC-1
 SCJP, SE 6
 Novell CLA / DCTS ECR
 DBA Postgres
 ---
 “A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” -
 Sábio Desconhecido
 Alguns prestam serviço/consultoria de Qualidade, os outros vendem
 licença!

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




-- 
Marcelo Silva

Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral