Re: [pgbr-geral] Nova camiseta "PostgreSQL Rock solid database"
Bom dia, Em 04-07-2016 22:28, Fábio Telles Rodriguez escreveu: Senhores, está à venda a nova camiseta que mandei fazer para a comunidade em comemoração aos 20 anos do PostgreSQL. Tem uma estampa na frente e outra atrás: http://www.lojadecamisetas.com/#!product-page/c1rx9/3fb64675-913e-543d-769a-49590130457e <http://www.lojadecamisetas.com/#%21product-page/c1rx9/3fb64675-913e-543d-769a-49590130457e> Tem as versões branca e preta por R$ 55. Para São Paulo o frete é de graça. O Frete também ficou grátis para Paraíba! 0/ Não estou levando nada na camiseta, se alguém quiser a arte eu posso mandar. Estou comprando as duas primeiras peguem a de vocês também! Parabéns pela iniciativa! Att, -- +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Crosstab com nome de colunas dinâmicas
5 | 3 LIMPEZA - FAZENDA | (null) | (null) | (null) | (null) | (null) | 1 | (null) | (null) | 2 | 3 | 4 | 3 MANUTENCAO - FAZENDA | (null) | (null) | (null) | (null) | 3 | (null) | (null) | 1 | 42 |104 |180 | 42 MATERIAIS DE EMBALAGEM| (null) | (null) | (null) | (null) | (null) | (null) | (null) | (null) | (null) | 1 | 1 | 1 MATERIAIS DE EMBALAGENS | 41 | 19 | 32 | 34 | 52 | 78 | 73 | 48 | 46 | 59 | 58 | 28 MATERIAIS DE EXPEDIENTE | 9 | 6 | 5 | 8 | 8 | 12 | 14 | 8 | 7 | 24 | 30 | 9 MATERIAIS DE LABORATORIO | 4 | 4 | 1 | 2 | 4 | 6 | 4 | 10 | 5 | 2 | 5 | 8 MATERIAIS DE LIMP.E CONSERV. | 13 | 10 | 11 | 15 | 19 | 18 | 19 | 18 | 17 | 35 | 36 | 10 Mas o crosstab não permite criar o nome destas colunas dinamicamente (a consulta só retorna os últimos 12 meses). Assim, tenho que encapsular a consulta em uma função e chamá-la em outras, uma para cada mês (e com isso formatando o nome das colunas de maneira correta). Existe alguma forma de fazer isto sem utilizar este artifício? Agradeço a ajuda, -- +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Case com Zebedee
Boa tarde Jean, Em 25-07-2014 08:32, Jean - GeControl escreveu: Utilizo Zebedee a um bom tempo.. é muito bom! Ele cria um tunel entre o server e o client e toda informação que trafega neste tunel é compactada, deixando assim a comunicação entre cliente/servidor mais rápida. Uma pergunta de leigo: qual a diferença, em termos de performance, entre uma ferramenta deste segmento e um túnel VPN sobre UDP compactado, como por exemplo, o OpenVPN? Tá aí, realmente não sei. Quem usa podia por aqui o case, sobre a diferença de performance, assim como Postgresql com SSL. O zebedee é muito leve, e no meu caso, não usei criptografia. Mas acredito que outras soluções do gênero ofereçam o mesmo benefício. Aproveitei alguns minutos do almoço e fiz uma avaliação rápida cruzando acesso direto e VPN com e sem SSL. Utilizei o seguinte cenário: * Consulta que me retorna 1.642 registros com aprox. 2MB de tráfego de texto plano; * O servidor encontra-se a 30 saltos (via traceroute) de onde estou no momento. Executei os comandos em uma maquina linux com conexão ADSL GVT; * Como estamos em um horário de produção e a ADSL nesses horário pode ser afetada, a repetição do comando gerou alguns dados com distorções significativas. então capturei o valor mais próximo entre eles de um total de 10 execuções com intervalo de 2 segundos entre as execuções; * A consulta executada em localhost no servidor do banco tem um tempo de 10.998 ms; * Para não considerar o tempo de autenticação e validação da senha, seja manual, por software ou via .pgpass, alterei os acessos do usuário para TRUST para os IPs utilizados (público de minha estação e da VPN). ##Execução com IP público #PSQL COM SSL habilitado $ export SSLMODE=required $ time psql portal -U daniel -h IP -c select * from tb_pedidos where fk_cliente = id /dev/null real0m1.823s user0m0.089s sys 0m0.009s #PSQL SEM SSL habilitado $ export SSLMODE=disable $ time psql portal -U daniel -h IP -c select * from tb_pedidos where fk_cliente = id /dev/null real0m2.072s user0m0.090s sys 0m0.012s ##Execução em VPN com comp-lzo habilitado #PSQL COM SSL habilitado $ export SSLMODE=required $ time psql portal -U daniel -h 10.1.0.10 -c select * from tb_pedidos where fk_cliente = id /dev/null real0m1.861s user0m0.090s sys0m0.010s ##PSQL SEM SSL habilitado $ export SSLMODE=disable $ time psql portal -U daniel -h 10.1.0.10 -c select * from tb_pedidos where fk_cliente = id /dev/null real0m1.785s user0m0.086s sys 0m0.013s Uma vez que o OpenVPN já é criptografado e esta com compactação habilitada, a melhor situação foi VPN com conexão ao banco SEM SSL. Apesar da diferença ser muito baixa. Espero que ajude. Att, -- +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Case com Zebedee
Em 24-07-2014 19:02, Renato Ricci escreveu: Utilizo Zebedee a um bom tempo.. é muito bom! Ele cria um tunel entre o server e o client e toda informação que trafega neste tunel é compactada, deixando assim a comunicação entre cliente/servidor mais rápida. Uma pergunta de leigo: qual a diferença, em termos de performance, entre uma ferramenta deste segmento e um túnel VPN sobre UDP compactado, como por exemplo, o OpenVPN? Att, -- +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] VIEWS com parâmetro
Em 05/02/2014 22:29, Fabrízio de Royes Mello fabri...@timbira.com.br
escreveu:
On 05-02-2014 15:01, Daniel Cordeiro wrote:
Obrigado pela correção Euler. Na ânsia de explicar uma forma de executar
o que se tinha interesse escrevi sem nem pensar na reescrita feita pelo
planejador antes da execução. Serei mais cuidadoso nas próximas!
Acontece que minha realidade para a consulta que impulsionou a escolha
por uma procedure ao invés de uma visão é bem diferente da exposta no
início deste tópico. Minha consulta possui diversas subqueryes com
definições de parâmetros e cálculos que não puderam ser
solucionados/otimizados com uso de CTEs ou views (e se tornou
impraticável para o momento a reescrita do modelo de negócio do banco).
E não apenas encapsular uma única condição.
Claro, sempre existe uma forma melhor de se fazer, o limite neste
contexto esta no meu 'universo conhecido' ;-P.
Daniel,
Creio que vc compreendeu bem porque o pessoal lhe indicou simplesmente
criar uma VIEW e que a mesma sofre um processo de reescrita antes de ser
executada, e com isso obtemos performance.
Entendi sim.
Então se mesmo assim vc precisa de um parametro em sua view, creio que
podes usar as funções set_config e current_setting [1] para criar uma
variável de sessão (ou use a extensão session_variables [2]).
Exemplo:
CREATE VIEW v_foo AS SELECT * FROM foo WHERE codigo =
current_setting('foo.codigo')::INTEGER;
Para executar:
SELECT set_config('foo.codigo', '1', false);
SELECT * FROM v_foo;
Não sei se isso lhe ajudará, até porque não compreendi bem o seu problema
de usar uma VIEW sem isso, e também tem a questão que vc terá se setar na
sessão o valor do seu parâmetro...
O problema na verdade não é meu, eu apenas tentei ajudar apresentando um
case onde utilizo funções no lugar de visões (no meu caso, utilizo a plsql
para testes e exceções).
Contudo, sua dica de sessão será muito útil para um outro case de
auditoria onde utilizo tabelas temporárias para armazenar um simples
valor. Obrigado pela dica!
Att,
[1] http://www.postgresql.org/docs/current/static/functions-admin.html
[2] http://pgxn.org/dist/session_variables/0.0.4/
--
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
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] VIEWS com parâmetro
Em 05-02-2014 19:46, Matheus de Oliveira escreveu: ... Sim, isso realmente poderia acontecer. Creio que o seu caso foi numa versão anterior à 9.2, correto? Na 9.2 o modelo de gerar plano de execução para prepared statements mudou, e ficou bem melhor. Agora o plano é gerado no EXECUTE, quando já são conhecidos os valores. Recomendo você a testar novamente essas funções numa versão mais recente (9.2 ou 9.3) e verificar se o comportamento ainda é o mesmo. Se o fizer, por favor compartilhe os resultados com os colegas, ;-)... Bingo!! Na época do caso, utilizávamos a versão 9.1. Migramos os sistemas para a versão 9.3 neste final de semana. Mas a frente realizarei alguns testes com as procedures antigas e posto os resultados aqui. Lembrando que estas ações podem dificultar a análise de um problema futuro, pois o EXPLAIN não vai detalhar o conteúdo interno executado na função e nem nos logs. +1. Otimizar funções é uma tarefa bem árdua. Só uma dica, a extensão auto_explain pode ajudar nessa tarefa. ;-) Obrigado pela dica! Vou estudar a extensão para verificar sua adoção em nosso ambiente. É, na minha opinião, um pré-requisito para quem usa muitas funções. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres http://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 Atenciosamente, -- +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] VIEWS com parâmetro
Em 05-02-2014 12:10, Euler Taveira escreveu: On 05-02-2014 11:41, Daniel Cordeiro wrote: Acredito que esta não seja uma opção tão 'performática', uma vez que a view vai gerar todos os dados e só depois é que o planejador realizará a restrição através do cláusula WHERE e ordenações necessárias. Você está equivocado. Nenhum dado é gerado por ser uma visão. Há uma etapa antes do planejamento que se chama reescrita. Nesta etapa, as visões são mescladas com a consulta informada e somente depois a árvore de consulta é passada para o planejador escolher o plano. Obrigado pela correção Euler. Na ânsia de explicar uma forma de executar o que se tinha interesse escrevi sem nem pensar na reescrita feita pelo planejador antes da execução. Serei mais cuidadoso nas próximas! Acontece que minha realidade para a consulta que impulsionou a escolha por uma procedure ao invés de uma visão é bem diferente da exposta no início deste tópico. Minha consulta possui diversas subqueryes com definições de parâmetros e cálculos que não puderam ser solucionados/otimizados com uso de CTEs ou views (e se tornou impraticável para o momento a reescrita do modelo de negócio do banco). E não apenas encapsular uma única condição. Claro, sempre existe uma forma melhor de se fazer, o limite neste contexto esta no meu 'universo conhecido' ;-P. O tempo de reescrita não é algo crítico (pelo menos nunca vi relatos). Além disso, é ingenuidade pensar que a execução de funções não tem custo inicial. Eu só usaria funções se precisasse de algo procedural (se bem que dá para fazer várias coisas procedurais com SQL :-). -- +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] VIEWS com parâmetro
Em 05-02-2014 11:55, Matheus de Oliveira escreveu:
...
', uma vez que a view vai gerar todos os dados e só depois é que o
planejador realizará a restrição através do cláusula WHERE e
ordenações necessárias.
humm... Sua afirmação não está correta. Dada a view teste a seguinte
consulta:
SELECT * FROM teste WHERE nome = 'matheus';
Passa por algumas transformações, primeiro:
SELECT * FROM (SELECT id_nome, nome FROM nomes) teste WHERE nome =
'matheus';
EXECUTE nunca é minha primeira opção
Em seguida, o PostgreSQL percebe que não precisa da subquery e
transforma a query acima em:
SELECT id_nome, nome FROM nomes AS teste WHERE teste.nome = 'matheus';
Resumindo, a view não vai gerar todos os dados, a consulta (acima) é
que será executada no final (claro ainda tem o plano de execução,
métodos de acesso, etc.).
Eu até diria que nesse exemplo específico a view me parece até mais
adequada e mais fácil de manter do que a função.
Como eu falei no email que respondi para Euler: My bad :-(
Minha sugestão é criar uma função que realiza a consulta já
adicionando as restrições necessárias para a triagem inicial dos
dados desejados.
Ex (descartando índices, segurança da função, etc)*1*.
/CREATE TABLE lancamentos (id int, conta text, campo1 text,
campo2 text);//
//
//INSERT INTO lancamentos
VALUES(1,'Produtivo','valor1','valor2');//
//INSERT INTO lancamentos
VALUES(2,'Produtivo','valor1','valor2');//
//INSERT INTO lancamentos
VALUES(3,'Mecanica','valor1','valor2');//
//INSERT INTO lancamentos
VALUES(4,'Mecanica','valor1','valor2');//
//
//CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA
varchar) RETURNS TABLE(i int, c1 text,c2 text, c text)//
//AS $$//
//
//BEGIN//
//RETURN QUERY SELECT id,conta,campo1,campo2 FROM
lancamentos WHERE conta = CODCONTA;//
//END;//
//$$//
//language 'plpgsql';/
OK. Realmente, para aceitar parâmetros da forma que o OP espera, é
necessário sim uma função.
Eu só recomendaria, nesse caso especificamente, a usar uma função SQL
ao invés de PL/pgSQL:
CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA varchar)
RETURNS TABLE(i int, c1 text,c2 text, c text)
AS $$
SELECT id,conta,campo1,campo2 FROM lancamentos WHERE conta =
CODCONTA;
$$
LANGUAGE SQL;
Para chamá-la:
SELECT * FROM sp_lancamentos('Produtivo');
(a chamada em si seria igual à PL/pgSQL, só quis exemplificar)]
Claro, usei o plpgsql por me basear em algo que já tinha, e o mesmo
depende dos recursos além da sql.
Para uma function muito grande e com muitas variáveis para
substituição, vale a pena utilizar a cláusula EXECUTE no RETURN
QUERY (isso já me salvou de vários problemas em functions com mais
mais de 1500 linhas e código e dezenas de variáveis)*2*:
/
RETURN QUERY EXECUTE 'SELECT id,conta,campo1,campo2 FROM
lancamentos WHERE conta = $1' USING CODCONTA;//
/
Ah? Por quê? Eu particularmente tento evitar o EXECUTE ao menos que
estritamente necessário. Lembre-se que ele não pode ser otimizado pelo
PL/pgSQL para armazenar o plano de execução.
Eu também não. Mas neste meu caso, após o crescimento de dados em alguns
clientes (alguns milhões de registros em dezenas de tabelas), o
QueryPlan dentro da procedure passou a ser tratado de maneira totalmente
diferente se comparado à execução da mesma query já com os valores
prefixados nas condicionais e subqueryes fora da procedure.
Aparentemente, como o prepare acontece antes do conhecimento dos
parâmetros na procedure, o planejador gerava um plano de execução mais
custoso. (novamente, esta foi a minha impressão sobre o caso).
Estou falando da mesma consulta rodando em 5 horas dentro da procedure e
7 segundos rodando fora. Inicialmente pensei que fosse a adoção do
RETURN QUERY. Ao modificar a procedure fazendo o retorno com o EXECUTE,
o tempo foi normalizado e o custo de operação dentro e fora da procedure
ficou, de fato, irrelevante.
Lembrando que estas ações podem dificultar a análise de um
problema futuro, pois o EXPLAIN não vai detalhar o conteúdo
interno executado na função e nem nos logs.
+1. Otimizar funções é uma tarefa bem árdua. Só uma dica, a extensão
auto_explain pode ajudar nessa tarefa. ;-)
Obrigado pela dica! Vou estudar a extensão para verificar sua adoção em
nosso ambiente.
Atenciosamente
--
+--+
| Daniel Cordeiro de Morais Neto
| Diretor de TI - Portal de Cotações e-Compras
| Sócio-diretor ADM Soluções em Informática LTDA
| daniel.cordeiro(at)cotacoesecompras.com.br
| dmoraisn(at)gmail.com
| www.cotacoesecompras.com.br
| Fone: (083)8724-4440
| Gentoo User
| http://twitter.com/dmoraisn
Re: [pgbr-geral] VIEWS com parâmetro
Em 04-02-2014 15:16, Matheus Saraiva escreveu: Como faço para criar uma view que receba um parâmetro que será usado na clausula WHERE ? Uma forma é encapsular sua consulta em uma function recebendo parâmetros e usando como returns TABLE. -- +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Retorno de valor padrão em SELECT
Boa tarde a todos, Possuo um sistema web onde o controle de usuários acontece através de tabelas de usuários e controle de permissões na aplicação. Para realizar o registro de mudanças nas tabelas por gatilhos, crio uma tabela temporária com o id do usuário e na hora de registrar as mudanças via trigger capturo desta tabela temporária o id do usuário armazenando os dados alterados com o usuário que realizou a operação na aplicação. Acontece que, algumas operações de backend rodam abaixo da aplicação, através de triggers e/ou chamadas internas via webservice. Para estas operações, a tabela temporária não vai existir e não posso inserir nenhum valor de uusário nela, mas nestes casos eu consigo realizar o controle através de usuários do próprio banco (cada aplicação de backend roda com um usuário específico do postgres). Na minha função, inicio a chamada para recolher o valor do usuário da seguinte forma: ... -- Cria o diretório temporário para ocaso da execução ser feita através das chamadas de backend CREATE TEMP TABLE IF NOT EXISTS tmp_usuario_logado (id_usuario_cliente VARCHAR(30)); -- Recupera o id do usuário, caso não exista (tabela recem criada), recupera o current_user do banco SELECT id_usuario_cliente INTO USUARIO_CLIENTE FROM (SELECT id_usuario_cliente::text AS id_usuario_cliente, 0 AS prioridade FROM tmp_usuario_logado UNION SELECT current_user AS id_usuario_cliente, 1 AS prioridade ORDER BY prioridade ASC LIMIT 1) AS dados_usuario; ... A operação em sim funciona e atende minha necessidade de auditoria (por usuário do banco ou por id do usuário do cliente). Sendo que, como realizamos muitas transações de insert, update,delete em lote, o tempo de criação desta tabela e o select no mesmo acaba ganhando proporções que podem impactar no desempenho do sistema no futuro. * Existe alguma forma de se criar uma variável dinâmica no Postgres setada na aplicação (por exemplo via SET) para que eu elimine a criação e consulta nesta tabela temporária? * No caso de não existir na atual versão do postgres (acabo de migrar para a 9.3.2), existe alguma forma de reduzir a operação deste select que estou usando? O Explain das operações (acontecem em cada operação de INSERT, DELETE, UPDATE *por linha*). CREATE TEMP TABLE IF NOT EXISTS tmp_usuario_logado (id_usuario_cliente VARCHAR(30)); CREATE TABLE Time: 6,246 ms --- EXPLAIN ANALYZE SELECT id_usuario_cliente INTO USUARIO_CLIENTE FROM (SELECT id_usuario_cliente::text AS id_usuario_cliente, 0 AS prioridade FROM tmp_usuario_logado UNION SELECT current_user AS id_usuario_cliente, 1 AS prioridade ORDER BY prioridade ASC LIMIT 1) AS dados_usuario; QUERY PLAN -- Subquery Scan on foo (cost=118.04..118.06 rows=1 width=32) (actual time=0.028..0.029 rows=1 loops=1) - Limit (cost=118.04..118.05 rows=1 width=4) (actual time=0.028..0.028 rows=1 loops=1) - Sort (cost=118.04..124.05 rows=2401 width=4) (actual time=0.027..0.027 rows=1 loops=1) Sort Key: (0) Sort Method: quicksort Memory: 25kB - HashAggregate (cost=82.03..106.04 rows=2401 width=4) (actual time=0.017..0.020 rows=2 loops=1) - Append (cost=0.00..70.02 rows=2401 width=4) (actual time=0.006..0.011 rows=2 loops=1) - Seq Scan on tmp_usuario_logado (cost=0.00..46.00 rows=2400 width=4) (actual time=0.006..0.007 rows=1 loops=1) - Subquery Scan on *SELECT* 2 (cost=0.00..0.02 rows=1 width=0) (actual time=0.003..0.003 rows=1 loops=1) - Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.002..0.002 rows=1 loops=1) Total runtime: 0.067 ms Atenciosamente, -- +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pgModeler
Em 2 de abril de 2013 08:26, Alex Wedsday alexweds...@hotmail.com mailto:alexweds...@hotmail.com escreveu: Bom dia, Pessoal! pgModeler não sabia que existia, muito bom gostei e vou economizar horas de trabalho. Obrigado gersoncjunior. No nosso caso aqui na empresa, tivemos problemas em utilizar a versão pré compilada para 32 bits em estações com Debian Wheezy. O problema principal estava no travamento da aplicação no momento que se criava relacionamentos. Resolvi o problema baixando os fontes e compilando novamente para a nossa versão. Se alguém estiver passando por problemas semelhantes no Debian Wheezy, basta solicitar em PVT quer mando o build para testarem. No mais, esta aplicação promete!!! []'s +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] modelo físico
Não sei se era este o link que o Dutra queria informar, mas foi o que achei indexado pelo google: https://docs.google.com/viewer?url=http%3A%2F%2Fdutra.fastmail.fm%2FPostgreSQL%2FFISL%2Filus.art.pdf Saudações, +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ Em 04-09-2012 16:47, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2012/9/4 Pedro Costa pedrocostaa...@sapo.pt: Estou a fazer um trabalho da universidade na qual desenvolvi uma base de dados em postgresql/postgis. Apresentei no manual o modelo conceptual que desenhei com o dia (na altura alguém aqui na lista deu-me essa dica). Agora estou a 'tratar de explicar o modelo físico'. A minha questão é se alguém tem ideia sobre a melhor maneira de o apresentar? Uma abordagem é usar o AutoDoc. Eu costumava usá-lo com um documento de programação literária LaΤεχ com SQL embutido; o LaΤεχ virava um PDF que incorporava os diagramas gerados pelo AutoDoc (ou pelo SQL::Fairy) do SQL que o noweb separava do LaΤεχ. Veja minha palestra _O Elefante ilustrado_ para detalhes e exemplos. ___ 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] Modo mais elegante para Like
Em 21-07-2011 16:35, Marcelo Silva (IG) escreveu: Pessoal, tenho o seguinte select SELECT * FROM TABELA WHERE (CAMPO1 LIKE 'STRING_A%') OR(CAMPO1 LIKE 'STRING_B%') OR(CAMPO1 LIKE 'STRING_C%') Observe que tenho que fazer varios ORs com Like porque as strings são o inicio de palavras SELECT * FROM TABELA WHERE CAMPO ~ E'^(STRING_A|STRING_B|STRING_C)'; Existe várias formas de se fazer com ER. +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PARA AUDITORIA
Olá Dickson, Eu possuo uma aplicação que roda um esquema de auditoria conforme vocês estão falando, sendo que, por ser uma aplicação WEB, não tenho como auditar o processo por usuário do banco. Os usuários se encontram em uma tabela de minha aplicação. Não é uma aplicação tão grande, com picos de 150 usuários simultâneos e média de 80 rodando 24x7. Para resolver esta situação, No momento em que o usuário se autentica, crio uma tabela temporária para a sessão com o id do usuário e os dados que necessito dele. Com isso, posso recuperar os dados do usuário pelas triggers de auditoria e registrar tudo que o usuário faz em um Schema independente do usuário do banco de dados. Sem precisar controlar a auditoria pela aplicação. Claro que, para melhorar a performance (não solicitar que a aplicação crie a cada execução a tabela temporária), utilizo conexões persistentes. Espero ter ajudado. +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ Em 11-07-2011 19:36, Dickson S. Guedes escreveu: Em 11 de julho de 2011 17:34, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: [...] - triggers nas tabelas que precisam de auditoria, essas triggers podem gravar alterações numa tabela de auditoria, lembrando que existe uma penalidade de performance aí. Já implementei auditoria assim. É a linha seguida pelo tablelog e pelo emaj, só que minha intenção era que o colega Eduardo descobrisse isso pesquisando as ferramentas que citei, mas agora você já revelou a surpresa... :( Aproveitando o tema, esse tipo de auditoria é interessante quando cada usuário da aplicação possui um usuário no banco. Já em aplicações que possuem um servidor de aplicação entre o cliente e o banco é comum existir um pool de conexões que utilizam um mesmo usuário para se conectar ao banco. Neste tipo de cenário é recomendado que a aplicação tome conta da auditoria. Distribuir a auditoria tanto na aplicação quando no banco de dados também é uma alternativa. Já utilizei as 3 (três) alternativas, e cada uma tem seus prós e contras. []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PARA AUDITORIA
Em 12-07-2011 14:28, Dickson S. Guedes escreveu:
Ola Daniel! [...]
Para resolver esta situação, No momento em que o usuário se autentica, crio
uma tabela temporária para a sessão com o id do usuário e os dados que
necessito dele. Com isso, posso recuperar os dados do usuário pelas triggers
de auditoria e registrar tudo que o usuário faz em um Schema independente do
usuário do banco de dados. Sem precisar controlar a auditoria pela
aplicação.
Fiquei curioso, como o banco sabe que aquela inserção ou alteração foi
feita pelo usuário 'A' e não pelo usuário 'B'? Ou você não mantém um
pool?
Na autenticação do usuário pela aplicação (autenticando em uma tabela de
contas de usuários), eu crio uma tabela temporária contendo todos os
dados necessários pelos meus gatilhos de auditoria. No momento que
acontece alguma modificação no sistema (normalmente autentico apenas
INSERT, UPDATE e DELETE),o gatilho recolhe os dados do usuário corrente
nesta tabela temporária (que é vista apenas pelo usuário da sessão).
Desta forma, mantenho os logs sempre pelo ID do usuário no sistema.
Um exemplo do código (escrito em PHP):
1- Parte: Criação da tabela
// {{{ Criando Tabela Temporária para armazenamento do
id_usuario_cliente corrente
$stmt = $conexao-query(SELECT table_schema,
table_name,
table_type
FROM
information_schema.tables
WHERE table_name =
'tmp_usuario_logado'
);
if ($stmt-fetchColumn(0)) {
// A tabela ainda não existe, então crio a tabela com os dados da
aplicação após terem sido autenticados no banco
$conexao-query(CREATE TEMP TABLE tmp_usuario_logado (id_usuario
VARCHAR(10)));
// Inserindo o id do usuario
$conexao-query(INSERT INTO tmp_usuario_logado VALUES
{$_SESSION['id_usuario']}());
...
}
2 - Gatilho recolhendo id no ato da atualização (feito em pl/perlu).
(Este modelo de auditoria eu acabei adaptando de um código
disponibilizado na internet a muitos anos atrás, como modifiquei muito e
já passaram por outros desenvolvedores, a fonte acabou se perdendo, mas
fica aqui o aviso dos créditos).
Código fonte|
| #-- Pegando o ID do usuario (o mesmo
sera pego de uma tabela temporaria)
| my $sql = SELECT id_usuario AS id FROM
tmp_usuario_logado;
| my $temp_id = spi_exec_query($sql);
|
| #-- Tipo de Evento (INSERT / UPDATE /
DELETE)
| my $evento = $_TD-{event};
|
| #-- OID da tabela que recebeu o comando
| my $oid_tabela = $_TD-{relid};
|
| #-- Nome da tabela que recebeu o comando
| my $tabela = $_TD-{relname};
|
| #-- Query para pegar o nome do esquema
| my $sql = SELECT schemaname AS esq
|FROM pg_catalog.pg_tables
| WHERE tablename = '$tabela';
| my $esquema = spi_exec_query($sql);
| $nome_esquema = $esquema-{rows}[0]-{esq};
|
| #-- Chave Primária da Tabela
| $pk_tabela = spi_exec_query(SELECT *
FROM public.pegaChavePk($oid_tabela) AS pk);
|
| my $chaves_primarias =
$pk_tabela-{processed};
| my $pk_coluna = ;
| my $pk_valor = ;
...
E por ai vai o código para recolher a os dados
...
*ATENÇÃO*
Existem um inconveniente (para alguns) deste modelo: quando necessito
realizar qualquer alteração direto no banco de dados, eu preciso
executar antes de qualquer coisa uma procedure que cria a estrutura de
tabela temporária (neste caso, com um usuário administrativo), caso
contrario, ele impede a operação (pode ser interessante por questões de
segurança).
Em tempo grato pela contribuição.
[]s
Guedes
Espero ter ajudado em algo.
+--+
| Daniel Cordeiro de Morais Neto
| Diretor de TI - Portal de Cotações e-Compras
| Sócio-diretor ADM Soluções em Informática LTDA
| daniel.cordeiro(at)cotacoesecompras.com.br
| dmoraisn(at)gmail.com
| www.cotacoesecompras.com.br
| Fone: (083)8724-4440
| Gentoo User
| http://twitter.com/dmoraisn
Re: [pgbr-geral] Uso do PREPARE dentro de uma RULE
/in/fabriziomello Obrigado pelo retorno. Atenciosamente, +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Uso do PREPARE dentro de uma RULE
boa tarde a todos, Tenho uma aplicação que a cada conexão do sistema, ele cria uma tabela temporária onde persiste informações que normalmente são utilizadas em algumas procedures em pl/perl. Acontece que estou querendo gerar uma rotina de histórico de procedimentos utilizando apenas rules, e um dos parâmetros essenciais e o id de quem realizou a operação (que consta nesta tabela temporária). Quando eu crio a rule e a tabela temporária já esta criada, a rule funciona sem problemas, só que quando eu reconecto ela não consegue encontrar a tabela temporária novamente (o schema pg_temp_*X* pode ter uma numeração diferente e parece que a rule não pesquisa no PATH do sistema). Precisando dar um replace na rule para ela funcionar. Pensei em utilizar PREPARE e EXECUTE para me trazer os dados, sendo que PREPARE esta dando problemas dentro da rule. Segue a rule: / / /CREATE or REPLACE RULE historico_cliente_associado AS ON UPDATE TO tb_clientes_associados / /DO INSTEAD(/ / PREPARE id_usuario AS/ / SELECT id_usuario_cliente / / FROM tmp_usuario_logado;/ // / INSERT INTO logs.tb_alteracoes_clientes_associados(nome_abreviado,/ / porcentagem_plano,/ ... / usuario_atualizou) / / values(old.nome_abreviado,/ / old.porcentagem_plano, ... // (EXECUTE id_usuario)/ / );/ / );/ Ele gera o seguinte erro: ERRO: erro de sintaxe em ou próximo a PREPARE LINHA 3: PREPARE id_usuario AS Alguém poderia ajudar? Grato, -- +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Large Objects
Olá, Luiz escreveu: Boa tarde a todos, Costumo armazenar no meu banco de dados fotos e também relatórios (arquivos .rpt). Os formatos utilizados são lo para os relatórios e bytea para as fotos. Sei que o PostgreSQL armazena os arquivos grandes em pg_catalog.pg_largeobject inclusive dividindo esses arquivos em diversos pedaços menores mais convenientes para serem armazenados. Alguém pode me dizer se somente os large objects (lo) são armazenados no pg_largeobject ou também algumas fotos grandes do tipo bytea podem ser armazenadas no pg_largeobject? Eu costumo utilizar pelo psql as funções \lo_list para visualizar os arquivos armazenados no banco de dados, para remover esses arquivos, é sempre bom utilizar o \lo_unlink OID para remover o arquivo do banco de dados. Lembrando para fazer a faxina no banco, é necessário periodicamente um vacuum para remover de fato o arquivo. Outra coisa, depois que passei a armazenar os relatórios no banco de dados, o tamanho do meu BD aumentou substancialmente chegando a mais de 10 vezes o seu tamanho original, sendo que armazeno uma média de 50 relatórios com 15K cada um. Desconfio que cada vez que atualizo os relatórios eles estão sendo duplicados no pg_largeobject e quando eu os deleto eles ainda continuam lá. O que eu posso estar fazendo de errado?? Esse armazenamento no pg_largeobject é feito totalmente por conta do PostgreSql certo?? então quando eu for deletar um relatório preciso fazer alguma coisa além de delete from tabela??? Se eu der um delete from pg_catalog.pg_largeobject, além de sumir com os meus relatórios, no que mais isso pode influenciar??? Obrigado!!! Espero ter ajudado Luiz Henrique Livrari Implantador de Sistemas Jr. MSI SOLUÇÕES Av. Dr. Altino Arantes, 131 Sala 145 - 146 Centro - Ourinhos/SP - Brasil Fone: +55 (14) 3324-8181 / (14) 3335-1849 www.msisolucoes.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- /* O único lugar aonde o sucesso vem antes do trabalho é no dicionário. (Albert Einstein) */ +--+ | Daniel Cordeiro de Morais Neto | | [EMAIL PROTECTED]| | Administrador de Redes | | ADM Soluções em Informática LTDA | | www.admsi.com.br | | F. (083)244-0757 | | Debian User - 453 - Sarge| | Gentoo User | +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
