[pgbr-geral] Datas, o que acontece com elas.
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.
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
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/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
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/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
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
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
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/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
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.
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.
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.
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.
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.
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?
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?
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?
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.
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
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