[pgbr-geral] Datas, o que acontece com elas.

2013-05-03 Por tôpico Joel Landim Mourão
Amigos, tenho a seguite situação:

my_table ( date timestamp );

select
  extract(epoch from DATE_TRUNC('day', date)) AS session_day,
  DATE_TRUNC('day', date) AS session_day2
FROM my_table

result:

1367452800;2013-05-02 00:00:00
1367539200;2013-05-03 00:00:00


select to_timestamp('1367452800')
result:
2013-05-01 21:00:00-03


Então o caso que notei, quando pego o resultado session_day2 ele me
responde no timezone correto apesar de não ter timezone no campo, porem
quando pelo o EPOCH do session_day ele ele aplica o timezone 0 e remove 3
horas do resultado, dai na minha APP estou tendo o dia errado, o EPOCH
esperado seria o que esta abaixo.

select to_timestamp('1367463600')
result:
2013-05-02 00:00:00-03

Alguém tem alguma idéia o porque deste comportamento? ou como posso pedir
para o epoch ignorar a questão do timezone e me entregar um unixtime
literal da data que estou lhe passando?

OBS. estou testando no 9.2.2


Att.
Joel Landim Mourã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] Datas, o que acontece com elas.

2013-05-03 Por tôpico Joel Landim Mourão
Em 3 de maio de 2013 15:37, JotaComm jota.c...@gmail.com escreveu:

 Olá,




 Em 3 de maio de 2013 12:34, Joel Landim Mourão jlmou...@gmail.comescreveu:

 Amigos, tenho a seguite situação:

 my_table ( date timestamp );


 Quando você cria uma tabela com apenas com timestamp você está criando uma
 tabela sem time zone, é como se sua tabela fosse criada assim:

 CREATE TEMP TABLE tmp(data TIMESTAMP); é igual a CREATE TEMP TABLE
 tmp(data TIMESTAMP WITHOUT TIME ZONE);



 select
   extract(epoch from DATE_TRUNC('day', date)) AS session_day,
   DATE_TRUNC('day', date) AS session_day2
 FROM my_table

 result:

 1367452800;2013-05-02 00:00:00
 1367539200;2013-05-03 00:00:00


 select to_timestamp('1367452800')
 result:
 2013-05-01 21:00:00-03


 Então o caso que notei, quando pego o resultado session_day2 ele me
 responde no timezone correto apesar de não ter timezone no campo, porem
 quando pelo o EPOCH do session_day ele ele aplica o timezone 0 e remove 3
 horas do resultado, dai na minha APP estou tendo o dia errado, o EPOCH
 esperado seria o que esta abaixo.





 select to_timestamp('1367463600')
 result:
 2013-05-02 00:00:00-03

 Alguém tem alguma idéia o porque deste comportamento? ou como posso pedir
 para o epoch ignorar a questão do timezone e me entregar um unixtime
 literal da data que estou lhe passando?

 OBS. estou testando no 9.2.2


 Agora vamos ao exemplo:

 CREATE TEMP TABLE tmp(data TIMESTAMP WITHOUT TIME ZONE);

 INSERT INTO tmp VALUES (localtimestamp(0));

 postgres=# SELECT * FROM tmp;
 data
 -
  2013-05-03 15:33:10
 (1 row)

 E quando você faz:

 postgres=# SELECT tmp.data,extract(epoch FROM
 date_trunc('day',tmp.data)),date_trunc('day',tmp.data) AS dia FROM tmp;
 data | date_part  | dia
 -++-
  2013-05-03 15:33:10 | 1367539200 | 2013-05-03 00:00:00
 (1 row)

 postgres=# SELECT to_timestamp(1367539200);
   to_timestamp
 
  2013-05-02 21:00:00-03
 (1 row)

 Agora vamos a documentação [1]:

 [1] http://www.postgresql.org/docs/9.2/interactive/functions-datetime.html

 epoch

 For timestamp with time zone values, the number of seconds since
 1970-01-01 00:00:00 UTC (can be negative); for date and timestamp values,
 the number of seconds since 1970-01-01 00:00:00 local time; for 
 intervalvalues, the total number of seconds in the interval

 Por isso que você tem esta diferença.


 Agora se você fizer:

 CREATE TEMP TABLE tmp(data TIMESTAMP WITH TIME ZONE);

 INSERT INTO tmp VALUES (localtimestamp(0));

 postgres=# SELECT * FROM tmp;
   data
 
  2013-05-03 15:35:59-03
 (1 row)

 SELECT tmp.data,extract(epoch FROM
 date_trunc('day',tmp.data)),date_trunc('day',tmp.data) AS dia FROM tmp;
   data  | date_part  |  dia
 ++
  2013-05-03 15:35:59-03 | 136755 | 2013-05-03 00:00:00-03

 postgres=# SELECT to_timestamp(136755);
   to_timestamp
 
  2013-05-03 00:00:00-03
 (1 row)

 Ao final você terá a resposta esperada.



Bom sua explicação foi muito boa e entendi a causa do problema. como
solução alterei o tipo do campo para adicionar o timezone, e tudo funcionou
como deveria.

Obrigado.

-- 
Joel Landim Mourão
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Parametros para uma PL

2013-04-10 Por tôpico Joel Landim Mourão
Boa tarde colegas,

Bom minha duvida, tenho uma necessidade de passar 15 parametros para uma
PL, existe alguma recomendação, ou sugestão para o caso.

Terei casos usando versão 9.2 e 8.2 (sendo atualizados gradualmente)

Obrigado a todos

-- 
Joel Landim Mourã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] Parametros para uma PL

2013-04-10 Por tôpico Joel Landim Mourão
2013/4/10 Dickson S. Guedes lis...@guedesoft.net

 Em 10 de abril de 2013 14:26, Joel Landim Mourão jlmou...@gmail.com
 escreveu:
  Boa tarde colegas,
 
  Bom minha duvida, tenho uma necessidade de passar 15 parametros para uma
 PL,
  existe alguma recomendação, ou sugestão para o caso.
 
  Terei casos usando versão 9.2 e 8.2 (sendo atualizados gradualmente)

 O que você deseja talvez seria variadic functions [1]?

 A partir da versão 8.4 as PLs permitem seu uso [2] nas PLs, alguns
 blogs [3,4] demonstram algumas aplicações práticas.

 [1] http://en.wikipedia.org/wiki/Variadic_function
 [2]
 http://www.postgresql.org/docs/9.1/static/xfunc-sql.html#XFUNC-SQL-VARIADIC-FUNCTIONS
 [3] http://www.depesz.com/2008/07/31/waiting-for-84-variadic-functions/
 [4]
 http://www.postgresonline.com/journal/archives/211-Variadic-Functions-in-PostgreSQL.html

 --



Em resposta das ultimas duas mensagens,

Bom a PL será chamada pela aplicação apenas.

Não preciso do uso do variadic, pois o numero de parametros é fixo, sem
contar que posso ter o problema por estar usando o 8.2 também.


-- 
Joel Landim Mourã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] Parametros para uma PL

2013-04-10 Por tôpico Joel Landim Mourão


 
 
 Mas... qual a dificuldade de usar os 15 parametros?
 ___


Boa tarde, não há dificuldade de uso, só busco mais conhecimento e
alternativas talvez até melhores do que listar os 15 parametros.

Obrigado a todos.

-- 
Joel Landim Mourã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] Versão do linux

2013-04-08 Por tôpico Joel Landim Mourão
2013/4/8 Marcone marconepe...@gmail.com

 Em 8 de abril de 2013 11:22, Ricardo Gomes rlgome...@hotmail.com
 escreveu:
  Uso o Debian
 

 +1

 --
 Marcone Peres - DBA
 http://www.linkedin.com/in/marconeperes
 @marconeperes
 (61) 8146-0028
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Bom dia,

Uso Slackware, minha segunda opção é o CentOS.


-- 
Joel Landim Mourã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] FATAL: 1 trigger record(s) not found for relation pg_authid

2013-03-01 Por tôpico Joel Landim Mourão
Em 1 de março de 2013 10:17, Matheus de Oliveira
matioli.math...@gmail.comescreveu:



 2013/3/1 Juliano Atanazio juliano.l...@gmail.com



 Em 1 de março de 2013 08:39, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:



 2013/2/28 Joel Landim Mourão jlmou...@gmail.com

 Em 28 de fevereiro de 2013 18:27, Fabrízio de Royes Mello 
 fabriziome...@gmail.com escreveu:


 On Thu, Feb 28, 2013 at 6:21 PM, Joel Landim Mourão 
 jlmou...@gmail.com wrote:


 Nos mostre o resultado do seguinte SELECT:

 select relname, reltriggers, relisshared from pg_class where relname
 = 'pg_authid';


 postgres=# select relname, reltriggers from pg_class where relname =
 'pg_authid';
   relname  | reltriggers
 ---+-
  pg_authid |   1
 (1 row)

 Ela existe no banco postgres mas não consigo entrar no outro banco
 como mostra o resultado a cima.


 Ok, mas vc não colocou a coluna relisshared no SQL conforme
 solicitei no outro email...

 Pedi para vc fazer isso pq a pg_authid é um catálogo global, então
 independente de qual banco vc realize o update o resultado estará visível
 para todos bancos do cluster...


 Segue os comandos:

 postgres=# select relname, reltriggers, relisshared from pg_class where
 relname = 'pg_authid';
   relname  | reltriggers | relisshared
 ---+-+-
  pg_authid |   1 | t
 (1 row)

 postgres=# update pg_class set reltriggers = (select count(*) from
 pg_trigger where tgrelid = pg_class.oid) where relname = 'pg_authid';
 UPDATE 1
 postgres=# \c uniconet

 FATAL:  1 trigger record(s) not found for relation pg_authid
 Previous connection kept

 Executei o update e mesmo assim sem acesso.


 Cara para evitar um desastre irreparável, faça um backup do diretório de
 dados: pare o serviço do PostgreSQL, copie o diretório data... Depois pode
 continuar...

 Mais uma coisa, versão 8.2.20? Você deve estar brincando né?

 Alguma coisa aconteceu em seu ambiente? Queda de energia? Problema de
 hardware? Faça testes de disco e memória e veja se encontra algum
 erro/alerta. Se for Linux (já que não disse a plataforma) dê uma olhada nos
 logs /var/log/messages* e veja se acha algum erro.


 É Slackware, Matheus.
 Eu já tinha perguntado isso tbm :)



 Ih... Eu não li isso... Foi mal...

 Agora então outra curiosidade: é um sistema em produção? Com Slackware?




 Sinceramente, estou achando que a solução para o seu problema vai ser
 mexer no código-fonte do PostgreSQL (super arriscado, por isso falei pra
 fazer backup do data antes) para ignorar o erro e ver se consegue pelo
 menos rodar um pg_dump... E, em seguida, restaurá-lo numa base nova (de uma
 versão nova também né?!)...

 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


 Realmente, Joel.
 Será que não é uma boa hora pra pensar numa atualização?
 Que tal fz um dump do cluster e montar um ambiente de homologação para
 versão atual (9.2.3)?
 Não sei se essa versão que vc está usando já haviam tirado CAST implícito.
 Se tem a boa prática de explicitar conversões não terá problemas :)




Vou tentar resumir, sim sistema em produção com Slackware, já estamos
criando um processo de migração do 8.2.x para o 9.2.x porém são muitos
clientes então ainda será um processo lento para todos estarem atualizados.

Bom quanto ao desastre acho que já se foi, como os dados contidos nos
clientes não são vitais, vamos aproveitar a catastrofe para atualizar.

Obrigado Srs.

-- 
Joel Landim Mourão
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] FATAL: 1 trigger record(s) not found for relation pg_authid

2013-02-28 Por tôpico Joel Landim Mourão
Boa tarde Srs.

Estou tendo esta mensagem em um banco em especifico:

FATAL:  1 trigger record(s) not found for relation pg_authid

Eu consigo locar no banco postgres, mas não consigo logar no banco da minha
aplicação, nem mesmo em --single

Versão do postgres 8.2.20

Existe algo que posso fazer para recuperar isso, pois já pesquisei na net e
não achei nada similar a isso.

Obrigado.

-- 
Joel Landim Mourã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] FATAL: 1 trigger record(s) not found for relation pg_authid

2013-02-28 Por tôpico Joel Landim Mourão
Em 28 de fevereiro de 2013 16:22, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 2013/2/28 Joel Landim Mourão jlmou...@gmail.com

 Boa tarde Srs.

 Estou tendo esta mensagem em um banco em especifico:

 FATAL:  1 trigger record(s) not found for relation pg_authid

 Eu consigo locar no banco postgres, mas não consigo logar no banco da
 minha aplicação, nem mesmo em --single

 Versão do postgres 8.2.20

 Existe algo que posso fazer para recuperar isso, pois já pesquisei na net
 e não achei nada similar a isso.


 Pelo visto houve alguma alteração indevida no seu catálogo (pg_class)...
 pois verificando os fontes vc caiu aqui [1]...

 Primeiro verifique se essa informação é verdadeira com o SQL abaixo:

 postgres=# select relname, reltriggers from pg_class where relname =
 'pg_authid';
   relname  | reltriggers
 ---+-
  pg_authid |   1
 (1 row)


 Provavelmente a sua coluna reltriggers deverá estar com um valor  1,
 então rode o update abaixo:

 postgres=# update pg_class set reltriggers = (select count(*) from
 pg_trigger where tgrelid = pg_class.oid) where relname = 'pg_authid';
 UPDATE 1


 Agora deve estar correto, então confira executando novamente o select
 anterior na pg_class...

 Espero ter ajudado.

 Att,


 [1]
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/trigger.c;h=e05917e278ce3097e140023cecde3dae96d7df3b;hb=fa1369a6b901bc1f7efa3d8386ffe5102f78c78a#l932

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


Boa noite,

Este é o grande problema, pois executar os comandos no banco do postgres
vai, mas não consigo nem entrar no banco com problema:

postgres=# \c uniconet
FATAL:  1 trigger record(s) not found for relation pg_authid
Previous connection kept
postgres=#


SO: Slackware - 12.2

-- 
Joel Landim Mourã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] FATAL: 1 trigger record(s) not found for relation pg_authid

2013-02-28 Por tôpico Joel Landim Mourão
2013/2/28 Fabrízio de Royes Mello fabriziome...@gmail.com



 2013/2/28 Joel Landim Mourão jlmou...@gmail.com


 Boa noite,

 Este é o grande problema, pois executar os comandos no banco do postgres
 vai, mas não consigo nem entrar no banco com problema:

 postgres=# \c uniconet
  FATAL:  1 trigger record(s) not found for relation pg_authid
 Previous connection kept
 postgres=#

 SO: Slackware - 12.2


 Nos mostre o resultado do seguinte SELECT:

 select relname, reltriggers, relisshared from pg_class where relname =
 'pg_authid';


postgres=# select relname, reltriggers from pg_class where relname =
'pg_authid';
  relname  | reltriggers
---+-
 pg_authid |   1
(1 row)

Ela existe no banco postgres mas não consigo entrar no outro banco como
mostra o resultado a cima.


-- 
Joel Landim Mourã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] FATAL: 1 trigger record(s) not found for relation pg_authid

2013-02-28 Por tôpico Joel Landim Mourão
Em 28 de fevereiro de 2013 18:27, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 On Thu, Feb 28, 2013 at 6:21 PM, Joel Landim Mourão jlmou...@gmail.comwrote:


 Nos mostre o resultado do seguinte SELECT:

 select relname, reltriggers, relisshared from pg_class where relname =
 'pg_authid';


 postgres=# select relname, reltriggers from pg_class where relname =
 'pg_authid';
   relname  | reltriggers
 ---+-
  pg_authid |   1
 (1 row)

 Ela existe no banco postgres mas não consigo entrar no outro banco como
 mostra o resultado a cima.


 Ok, mas vc não colocou a coluna relisshared no SQL conforme solicitei no
 outro email...

 Pedi para vc fazer isso pq a pg_authid é um catálogo global, então
 independente de qual banco vc realize o update o resultado estará visível
 para todos bancos do cluster...


Segue os comandos:

postgres=# select relname, reltriggers, relisshared from pg_class where
relname = 'pg_authid';
  relname  | reltriggers | relisshared
---+-+-
 pg_authid |   1 | t
(1 row)

postgres=# update pg_class set reltriggers = (select count(*) from
pg_trigger where tgrelid = pg_class.oid) where relname = 'pg_authid';
UPDATE 1
postgres=# \c uniconet

FATAL:  1 trigger record(s) not found for relation pg_authid
Previous connection kept

Executei o update e mesmo assim sem acesso.

-- 
Joel Landim Mourão
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Tratando integridade de dados.

2013-02-19 Por tôpico Joel Landim Mourão
Boa tarde amigos,

A um tempo tive um problema relacionado a integridade em uma tabela de
login de terminais, pois havia alguns dados que intercalavam data de
inicio/fim dando assim duplicidades em minhas buscas, exemplo:


id user - ip - data_login - data_logout
1 - 192.168.0.10 - 2013-01-01 00:00:00 - 2013-01-01 10:00:00
3 - 192.168.0.10 - 2013-01-01 08:00:00 - 2013-01-01 14:00:00


No meu select que a chave de busca é o ip e o horario do evento, sempre
teria o erro em um determinado horario.
Mas alem do erro do select, existia o problema haver dois logins do mesmo
terminal em horario conflitante, afinal não posso ter mais de um login por
terminal no mesmo intervalo.

A solução que adotamos foi, criamos uma coluna int que teria o default
sendo 0, e quando houvesse o logout trocaria o valor por um sequencial, e
colocamos um UNIQUE(ip_terminal, lock_controller), desta forma
foi possível evitar mais de um insert na tabela do memo ip no mesmo
intervalo. Usando uma trigger para controlar este processo.

A pergunta é, existe alguma outra técnica que eu poderia ter adotado?

Esta esta sendo uma solução que esta funcionando, claro que venho colocar a
questão na lista para criar novas opções e se melhores ou mais corretas
adota-las.

Segue a estrutura da tabela com a trigger que controla o campo
lock_controller.

CREATE TABLE log_usuario
(
  id serial NOT NULL,
  fk_usuario_id integer NOT NULL,
  ref_usuario_login_id integer NOT NULL,
  data_login timestamp without time zone NOT NULL DEFAULT now(),
  data_logout timestamp without time zone,
  ip_terminal inet NOT NULL,
  lock_controller integer NOT NULL DEFAULT 0,
  CONSTRAINT log_usuario_pkey PRIMARY KEY (id),
  CONSTRAINT unique_ip_logged_in UNIQUE (ip_terminal, lock_controller)
);

CREATE TRIGGER log_usuario_pre_trigger
  BEFORE INSERT OR UPDATE
  ON log_usuario
  FOR EACH ROW
  EXECUTE PROCEDURE fn_tg_log_usuario_lockcontroller();


CREATE OR REPLACE FUNCTION fn_tg_log_usuario_lockcontroller()
  RETURNS trigger AS
$BODY$
BEGIN
IF (TG_OP = 'UPDATE') THEN
IF NEW.data_logout IS NOT NULL THEN
NEW.lock_controller =
nextval('log_usuario_ip_lockcontroller'::regclass);
END IF;
RETURN NEW;
ELSIF (TG_OP = 'INSERT') THEN
NEW.lock_controller = 0;
RETURN NEW;
END IF;

RETURN NULL;
END;
$BODY$
  LANGUAGE plpgsql;


Desde já obrigado a todos.

-- 
Joel Landim Mourã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] Tratando integridade de dados.

2013-02-19 Por tôpico Joel Landim Mourão
Em 19 de fevereiro de 2013 18:06, Euler Taveira eu...@timbira.comescreveu:

 On 19-02-2013 17:47, Joel Landim Mourão wrote:
  A pergunta é, existe alguma outra técnica que eu poderia ter adotado?
 
 Você não disse a versão que está utilizando mas se for 9.2, você pode
 utilizar
 tipos para intervalo (aka range types) [1]. Eles são tipos para intervalo
 como, por exemplo, intervalos de data ou de números. Eles suportam
 restrições
 e indexação.

 Se for versão inferior a 9.2, a única solução é implementar as restrições
 na mão.


 [1] http://www.postgresql.org/docs/current/static/rangetypes.html


Existem duas versões usadas ainda hoje, a 8.2.x e já estou começando
distribuir a 9.2.x em breve estaremos estudando como migrar o pessoal da
8.2.x para a mais nova, mas por hora vai ser mantido ambas as versões.

E mesmo não usando inicialmente vou olhar o link indicado.

-- 
Joel Landim Mourão
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Dar uma força para o processo do vacuum.

2012-12-13 Por tôpico Joel Landim Mourão
Boa tarde,

Sei que o processo do vacuum precisa ser feito com mais frequencia,
mas por um erro de projeto acabamos hoje usando ainda a versão 8.2.x
mas em processo de migração para 9.2.x, em alguns clientes precisamos
executar o vacuum, porém em alguns casos ele fica dias executando,
dois, tres dias.

Temos condições de parar a aplicação para fazer as manutenções
necessárias, existe alguma dica, para que eu possa ter mais agilidade
no processo do vacuum?

Só para complementar, não são grandes servidores, em alguns casos o
disco é pequeno  200Gb e o banco tem cerca de 100~150Gb, a manutenção
normalmente vem com DELETE, e ja estou estudando a possbilidade de
fazer particionamento de tables.

Desde já, obrigado.

-- 
Joel Landim Mourã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] Dar uma força para o processo do vacuum.

2012-12-13 Por tôpico Joel Landim Mourão
Em 13 de dezembro de 2012 17:15, Matheus de Oliveira
matioli.math...@gmail.com escreveu:
 2012/12/13 Joel Landim Mourão jlmou...@gmail.com

 Boa tarde,


 Boa tarde.


 Sei que o processo do vacuum precisa ser feito com mais frequencia,
 mas por um erro de projeto acabamos hoje usando ainda a versão 8.2.x
 mas em processo de migração para 9.2.x, em alguns clientes precisamos
 executar o vacuum, porém em alguns casos ele fica dias executando,
 dois, tres dias.


 8.2.x??? Nem vou comentar... xD

 Você não disse como está fazendo esse procedimento.


Depende do caso, mas normalmente tem sido feito por comando: vacuum -af



 Temos condições de parar a aplicação para fazer as manutenções
 necessárias, existe alguma dica, para que eu possa ter mais agilidade
 no processo do vacuum?


 CLUSTER ou pg_reorg (que não sei se vai funcionar nessa versão).



 Só para complementar, não são grandes servidores, em alguns casos o
 disco é pequeno  200Gb e o banco tem cerca de 100~150Gb, a manutenção
 normalmente vem com DELETE, e ja estou estudando a possbilidade de
 fazer particionamento de tables.


 Particionamento? Por que está pensando nisso?

O caso do particionamento eu tratei em outro post, esta relacionado a
demora em algumas consultas, pois somente uma tabela costuma crescer
100~200Gb e como a app é pequena e usa pouco recurso de hardware
preciso redimensionar para melhorar.


 Sem mais detalhes de tudo, como está o ambiente, como e porquê você executa
 essas operações, vai ficar difícil ajudar.


No geral é para liberar espaço em disco, como é uma tabela só que
costuma ficar inchada, e ela não recebe deletes nem updates comumente,
dai só sob demanda executamos o procedimento de delete, outro fator
para o uso do particionamento.



 Atenciosamente,
 --
 Matheus de Oliveira
 Analista de Banco de Dados PostgreSQL
 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




-- 
Joel Landim Mourã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] Dar uma força para o processo do vacuum.

2012-12-13 Por tôpico Joel Landim Mourão
Em 13 de dezembro de 2012 17:18, PostgreSQL [VORio]
postgre...@vorio.com.br escreveu:
 Olá Joel.

 Nesta versão, acho mais eficiente fazer um CLUSTER nas tabelas que
 precisa, ao invés de fazer o vacuum.
 Fica mais eficiente e leva bem menos tempo pra fazer.   Uma coisa não
 muito boa é que vai precisar de mais espaço livre em disco pra fazer
 esta operação.
 Se puder, drope os índices que não são PK antes do cluster e recrie-os
 depois de terminado.
 Mas seria uma boa vcs pensarem também em migrar o banco para uma versão
 atual.

Farei o teste do CLUSTER, e sim, já estamos iniciando o processo de
migração, mas isso ainda vai tempo por causa do numero de clientes.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Particionamento de tabelas fazer ou não?

2012-12-07 Por tôpico Joel Landim Mourão
Boa tarde amigos,

Andei lendo sobre o assunto depois de ter participado do PGDAY-SP, mas
alguns documentos dizem que não é recomendável que o particionamento não
traga muitos particionamentos, eu consigo particionar em meses, mas meus
clientes costumam manter os dados por mais de dois anos, ainda é aceitável
que eu tenha este tipo de particionamento?

Outra questão, todos os realtórios gerados são baseado apenas em dia, nunca
em intervalo que intercale um dia com o outro, caso isso aconteça a
apresentação sera separada em dia da mesma forma.

Existem outros relatórios que são materializados em outras tabelas, mas
tudo seguindo o padrão de dias.

Eu tenho condições de ajustar a minha aplicação para que em vez de ter uma
tabela mãe, eu consulte sempre as tabelas particionadas.

Olhando este cenário, é um caminho aceitável e ou até recomendável para
minha aplicação, considerando que esta tabela que será particionada já
chegou a ter 180GB em 2 anos em alguns clientes, e é importante dizer, a
app e o banco estão no mesmo servidor por não ser de nivel critico ou de
muitas conexões, até hoje não mais que 200 conexões (localhost) simultaneas
em nossos maiores clientes.

-- 
Joel Landim Mourã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] Particionamento de tabelas fazer ou não?

2012-12-07 Por tôpico Joel Landim Mourão
Em 7 de dezembro de 2012 12:52, Danilo Silva
danilo.dsg.go...@gmail.comescreveu:

 Em 7 de dezembro de 2012 12:19, Joel Landim Mourão 
 jlmou...@gmail.comescreveu:

 Boa tarde amigos,

 Andei lendo sobre o assunto depois de ter participado do PGDAY-SP, mas
 alguns documentos dizem que não é recomendável que o particionamento não
 traga muitos particionamentos, eu consigo particionar em meses, mas meus
 clientes costumam manter os dados por mais de dois anos, ainda é aceitável
 que eu tenha este tipo de particionamento?

 Outra questão, todos os realtórios gerados são baseado apenas em dia,
 nunca em intervalo que intercale um dia com o outro, caso isso aconteça a
 apresentação sera separada em dia da mesma forma.

 Existem outros relatórios que são materializados em outras tabelas, mas
 tudo seguindo o padrão de dias.

 Eu tenho condições de ajustar a minha aplicação para que em vez de ter
 uma tabela mãe, eu consulte sempre as tabelas particionadas.


 Se não me engano, não será necessário efetuar consulta nas tabelas
 filhas, uma vez que, quem cuida deste processo é a tabela pai, ou seja,
 se você tem um particionamento em meses (JAN, FEV, MAR) e quiser efetuar
 uma consulta que traga registros de dois meses por exemplo, o seu select
 será na tabela pai e ele irá consultar nas tabelas filhas os registros
 que atendem a sua consulta.


Bom como coloquei antes, não tenho esta questão de intercalar os
intervalos, pois a app pode ser moldada de acordo, sendo assim
desnecessário o uso da tabela pai, mesmo que eu tenha um intervalo que
busque em partições diferentes, e desta forma acho que será desnecessário o
uso de uma tabela pai neste cenário.

-- 
Joel Landim Mourã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] Particionamento de tabelas fazer ou não?

2012-12-07 Por tôpico Joel Landim Mourão
Em 7 de dezembro de 2012 14:34, Matheus de Oliveira 
matioli.math...@gmail.com escreveu:

 2012/12/7 Joel Landim Mourão jlmou...@gmail.com

 Boa tarde amigos,

 Andei lendo sobre o assunto depois de ter participado do PGDAY-SP, mas
 alguns documentos dizem que não é recomendável que o particionamento não
 traga muitos particionamentos,


 Depende. Não é recomendado muitas partições, 100 seria um limite (não
 exato), agora, quanto à número mínimo de partições não vejo nenhuma
 restrição.


  eu consigo particionar em meses, mas meus clientes costumam manter os
 dados por mais de dois anos, ainda é aceitável que eu tenha este tipo de
 particionamento?


 Acredito que dependerá mais da quantidade de informações que tem
 armazenada do que no tempo em que elas permanecem lá. É claro que fazer
 expurgo de partições inteiras é bem mais rápido, é esse o caso?



 Outra questão, todos os realtórios gerados são baseado apenas em dia,
 nunca em intervalo que intercale um dia com o outro, caso isso aconteça a
 apresentação sera separada em dia da mesma forma.


 De qualquer forma, sempre que exibe um dia você iria em uma só partição, e
 não precisaria buscar em várias. Você poderia inclusive particionar por ano
 ou por semestre (ou outro padrão, como intervalos de ID), diminuindo a
 quantidade de partições. Não precisa ser exatamente dia ou mês.



 Existem outros relatórios que são materializados em outras tabelas, mas
 tudo seguindo o padrão de dias.

 Eu tenho condições de ajustar a minha aplicação para que em vez de ter
 uma tabela mãe, eu consulte sempre as tabelas particionadas.


 Para o particionamento do PostgreSQL, na maioria dos casos, não precisa
 mudar nada na aplicação, a não ser que não use a chave da partição nas
 consultas.


Como se trata de uma aplicação distribuida eu terei de moldar o sistema
para que ele seja capaz de criar as proprias partições e toda sua
estrutura, pois não há como ter uma manutenção a cada cliente a cada mês,
por isso a mudança no comportamento do sistema talvez seja mais
interessante apesar de mais arriscado.





 Olhando este cenário, é um caminho aceitável e ou até recomendável para
 minha aplicação, considerando que esta tabela que será particionada já
 chegou a ter 180GB em 2 anos em alguns clientes, e é importante dizer, a
 app e o banco estão no mesmo servidor por não ser de nivel critico ou de
 muitas conexões, até hoje não mais que 200 conexões (localhost) simultaneas
 em nossos maiores clientes.


 Cara, como já disse, vai depender da quantidade de registros dessa tabela
 (do tamanho deles também) e o padrão/modelo de acesso, em muitos casos
 180GB não é considerado assim tão grande.

 Primeiro pergunte-se o porquê de você estar buscando o particionamento.
 Está enfrentando problemas de performance? É para agilizar o expurgo de
 dados? Muitos buracos na tabela?


Sim o objetivo é a performance pois existem alguns relatórios que ficam
extremamente lentos mas quando isolo um numero menor de registros isso já
me da um resultado aceitável e o expurgo de periodos sempre basados em
mêses.



 Atenciosamente,
 --
 Matheus de Oliveira
 Analista de Banco de Dados PostgreSQL
 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




-- 
Joel Landim Mourão
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] update de status da table.

2012-11-22 Por tôpico Joel Landim Mourão
Boa noite,

Talvez o assunto não faça muito sentido, mas vou tentar explicar.
Tenho uma table, e preciso cachear ela em memcached para uma app, porém o
conteudo desta table pode não mudar por um intervalo muito grande, mas o
time de refresh para meu cache é 1s.
Esta tabela pode conter 10 como 1000 registros, e sofrer inserts/deletes
exporadicamente.

A pergunta é, o postgres mantém alguma informação do tipo, ultimo
update(qualquer alteração) da table em tal hora, de forma que eu possa
manter esta informação externa e em vez de ficar dando reload nos dados a
cada 1s, eu consulto isso, se nao houve alteração, eu não faço nada, se
houve dai eu busco os Xmil registros.

Eu sei que eu posso fazer uma trigger em conjunto com uma tables de estado
minha, só quero saber mesmo se o postgres tem algum tipo de informação
deste tipo, evitando assim uma trigger na minha app.

E já agradesço as respostas.

-- 
Att.
Joel Landim Mourã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] Restore postgres! traumatico

2012-11-20 Por tôpico Joel Landim Mourão
Boa tarde amigo,

Eu ja tive alguns problemas do tipo, isso normalmente se dava quando eu
desejava restaurar dados de um dump em tabelas que estão em produção e
tinha um campo sequencial resetado a 0.

Cláro que era uma açõa muito erronea de minha parte, então eu tinha algumas
formas de agir neste caso, primeiro dando um truncate na table que tinha a
duplicidade de dados, isso se os dados presentes não fossem importantes, a
outra seria imagina que o final da chave sequencial seria tal numero, e dai
eu dava um UPDATE somando aquela chave atual dos dado existente no momento
com +10 por exemplo, outra forma é restaurar em uma tabela de
transição, ver quais são os registros duplicados e dai tentar corrigi-los.

Bom, não estou dizendo que estas praticas são as melhores ou que são as
unicas, obviamente deve existir praticas mais eficientes e aceitaveis por
DBAs, mas infelizmente sou um simples coder rsrs... e os DBAs vão me matar
pela dica.

Abraços

Joel


Em 20 de novembro de 2012 10:50, Juliano Atanazio
juliano.l...@gmail.comescreveu:



 Em 20 de novembro de 2012 10:09, rodrigo systemas 
 rodrigo.syste...@gmail.com escreveu:


 Pessoal! estou apanhando da restauração do backup do postgres... da erro
 de TOC...dia que tem chaves duplicadas e etc...alguem ja passou por isso?


 Tem como detalhar mais o processo que vc fez para fazer esse backup e sua
 respectiva restauração?




 Rodrigo

 ___
 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




-- 
Joel Landim Mourão
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral