Re: [pgbr-geral] work_mem por requisição
Aggregate (cost=21.88..21.97 rows=1 width=42) (actual time=0.734..0.734 rows=1 loops=1) - Nested Loop Left Join (cost=0.00..21.80 rows=1 width=42) (actual time=0.057..0.453 rows=25 loops=1) - Nested Loop Left Join (cost=0.00..19.52 rows=1 width=41) (actual time=0.051..0.329 rows=25 loops=1) Filter: (NotaFiscal.CodigoNotaMatrizNota IS NULL) *O filter acima, é destinado a um campo do inteiro e que tem índice mas o planejador não consegue usar* - Index Scan using NotaItem_Empresa_Produto_Data_Situacao_I on NotaItem (cost=0.00..10.89 rows=1 width=41) (actual time=0.038..0.095 rows=25 loops=1) Index Cond: ((CodigoEmpresaItem = 77222) AND (CodigoProdutoItem = 27149) AND (DataMovimentoItem = '2013-12-01'::date) AND (DataMovimentoItem = '2013-12-31'::date)) Filter: (SituacaoNotaItem IS NULL) *O filter acima, é destinado a um campo do varchar(1) e que tem índice mas o planejador não consegue usar* - Index Scan using NotaFiscal_CodigoInterno_PK on NotaFiscal (cost=0.00..8.62 rows=1 width=12) (actual time=0.005..0.006 rows=1 loops=25) Index Cond: (NotaItem.CodigoNotaItem = NotaFiscal.CodigoInternoNota) - Index Scan using Operacao_CodigoInterno_PK on Operacao (cost=0.00..2.27 rows=1 width=9) (actual time=0.002..0.003 rows=1 loops=25) Index Cond: (NotaFiscal.CodigoOperacaoEstoqueNota = Operacao.CodigoInternoOperacoes) Total runtime: 1.053 ms O tempo não é ruim mas da para ser melhor! Um detalhe importante que esqueci de falar, é que a versão do banco que uso é 8.2.23. Estamos com planos para mudar para a mais nova versão, ma dependemos que componentes de terceiros para a nossa linguagem ajustem seus processos também para a nova versão. Na verdade, estamos presos a espera dos outros!!! Marcos André G.A Trabin Softwarre Consulting - www.trabin.com.br *Blog:* http://lgerardlucas.blogspot.com/ *twitter:* http://twitter.com/lgerardlucas Em 30 de janeiro de 2014 20:42, Matheus de Oliveira matioli.math...@gmail.com escreveu: 2014-01-30 Marcos - GMail lgerardlu...@gmail.com Pessoal, uma vez assisti algumas palestras de postgresql e em uma delas, alguém falou sobre a possibilidade de alterar o parâmetro work_mem por sessão. Por exemplo: 40 usuários requisitando diversos relatórios dos quais todos tem ordenação. Verifique a possibilidade de criação de índices que casam com o ORDER BY, muitas vezes evitará por completo a necessidade de uso de memória ou disco para ordenação, o próprio índice trará os dados já ordenados. Se quiser, envie-nos o EXPLAIN ANALYZE dessas consultas que podemos ajudar com dicas de bons índices ou configurações adequadas. Nestas consultas, considerando que todas foram feitas em plpgsql, na primeira linha das mesmas, eu teria o comando *set work_mem = '15MB'; * Em funções PL/pgSQL, é fácil: CREATE OR REPLACE FUNCTION public.dah() * SET work_mem TO '15MB'* AS $$ ... $$; *É uma boa práticas? * Bem, isso vai depender o quanto de memória disponível que seu servidor possuirá. Pode ser até possível já manter 15MB para todos (o padrão, 1MB, é bem conservativo). A conta geral é que seria usado até (work_mem * max_connections) de memória para ordeanação/bitmap/etc. A realidade é que pode ser mais do que isso, mas essa é uma boa estimativa (já que muitas sessões vão usar menos). Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] work_mem por requisição
Em 31 de janeiro de 2014 08:16, Marcos - GMail lgerardlu...@gmail.comescreveu: Aggregate (cost=21.88..21.97 rows=1 width=42) (actual time=0.734..0.734 rows=1 loops=1) - Nested Loop Left Join (cost=0.00..21.80 rows=1 width=42) (actual time=0.057..0.453 rows=25 loops=1) - Nested Loop Left Join (cost=0.00..19.52 rows=1 width=41) (actual time=0.051..0.329 rows=25 loops=1) Filter: (NotaFiscal.CodigoNotaMatrizNota IS NULL) *O filter acima, é destinado a um campo do inteiro e que tem índice mas o planejador não consegue usar* - Index Scan using NotaItem_Empresa_Produto_Data_Situacao_I on NotaItem (cost=0.00..10.89 rows=1 width=41) (actual time=0.038..0.095 rows=25 loops=1) Index Cond: ((CodigoEmpresaItem = 77222) AND (CodigoProdutoItem = 27149) AND (DataMovimentoItem = '2013-12-01'::date) AND (DataMovimentoItem = '2013-12-31'::date)) Filter: (SituacaoNotaItem IS NULL) *O filter acima, é destinado a um campo do varchar(1) e que tem índice mas o planejador não consegue usar* - Index Scan using NotaFiscal_CodigoInterno_PK on NotaFiscal (cost=0.00..8.62 rows=1 width=12) (actual time=0.005..0.006 rows=1 loops=25) Index Cond: (NotaItem.CodigoNotaItem = NotaFiscal.CodigoInternoNota) - Index Scan using Operacao_CodigoInterno_PK on Operacao (cost=0.00..2.27 rows=1 width=9) (actual time=0.002..0.003 rows=1 loops=25) Index Cond: (NotaFiscal.CodigoOperacaoEstoqueNota = Operacao.CodigoInternoOperacoes) Total runtime: 1.053 ms É.. no caso seria um aggregate e não uma ordenação, como havia dito antes. Isso já muda um pouco as coisas, visto que a recomendação de índices sugerida pelo Matheus serviria para ordenação. Mesmo assim, você tem um índice CodigoNotaMatrizNota IS NULL ou só CodigoNotaMatrizNota? []'s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Pesquisar em campo Text
Pessoal bom dia, como posso encontrar registros que estão com a descrição do produto duplicada . o campo descrição é do tipo Text. Usando o operador Like consegui recuperar bastante registros, mas não todos. Usando o full text search encontrei mais do que realmente existe por causa da similaridade mesmo diminuindo a quantidade de palavras no arquivo de stop words. Estou fazendo testes no Postgresql 9.3 . obrigado Stéfano___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] work_mem por requisição
CREATE INDEX NotaFiscal_CodigoNotaMatrizNota_I ON NotaFiscal USING btree (CodigoNotaMatrizNota ); Marcos André G.A Trabin Softwarre Consulting - www.trabin.com.br *Blog:* http://lgerardlucas.blogspot.com/ *twitter:* http://twitter.com/lgerardlucas Em 31 de janeiro de 2014 09:02, Rafael Fialho Corrêa r.fia...@ibest.com.brescreveu: Em 31 de janeiro de 2014 08:16, Marcos - GMail lgerardlu...@gmail.comescreveu: Aggregate (cost=21.88..21.97 rows=1 width=42) (actual time=0.734..0.734 rows=1 loops=1) - Nested Loop Left Join (cost=0.00..21.80 rows=1 width=42) (actual time=0.057..0.453 rows=25 loops=1) - Nested Loop Left Join (cost=0.00..19.52 rows=1 width=41) (actual time=0.051..0.329 rows=25 loops=1) Filter: (NotaFiscal.CodigoNotaMatrizNota IS NULL) *O filter acima, é destinado a um campo do inteiro e que tem índice mas o planejador não consegue usar* - Index Scan using NotaItem_Empresa_Produto_Data_Situacao_I on NotaItem (cost=0.00..10.89 rows=1 width=41) (actual time=0.038..0.095 rows=25 loops=1) Index Cond: ((CodigoEmpresaItem = 77222) AND (CodigoProdutoItem = 27149) AND (DataMovimentoItem = '2013-12-01'::date) AND (DataMovimentoItem = '2013-12-31'::date)) Filter: (SituacaoNotaItem IS NULL) *O filter acima, é destinado a um campo do varchar(1) e que tem índice mas o planejador não consegue usar* - Index Scan using NotaFiscal_CodigoInterno_PK on NotaFiscal (cost=0.00..8.62 rows=1 width=12) (actual time=0.005..0.006 rows=1 loops=25) Index Cond: (NotaItem.CodigoNotaItem = NotaFiscal.CodigoInternoNota) - Index Scan using Operacao_CodigoInterno_PK on Operacao (cost=0.00..2.27 rows=1 width=9) (actual time=0.002..0.003 rows=1 loops=25) Index Cond: (NotaFiscal.CodigoOperacaoEstoqueNota = Operacao.CodigoInternoOperacoes) Total runtime: 1.053 ms É.. no caso seria um aggregate e não uma ordenação, como havia dito antes. Isso já muda um pouco as coisas, visto que a recomendação de índices sugerida pelo Matheus serviria para ordenação. Mesmo assim, você tem um índice CodigoNotaMatrizNota IS NULL ou só CodigoNotaMatrizNota? []'s ___ 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] work_mem por requisição
Em 31 de janeiro de 2014 09:38, Marcos - GMail lgerardlu...@gmail.comescreveu: CREATE INDEX NotaFiscal_CodigoNotaMatrizNota_I ON NotaFiscal USING btree (CodigoNotaMatrizNota ); Não sei se vai adiantar muita coisa, porque vai depender muito da quantidade de registros e do próprio plano de execução, mas tente executar os seguintes comandos e veja se melhora alguma coisa: CREATE INDEX NotaFiscal_CodigoNotaMatrizNota_IsNull_I ON NotaFiscal USING btree (CodigoNotaMatrizNota) WHERE (CodigoNotaMatrizNota IS NULL; analyze NotaFiscal; Creio que aumentar o work_mem, neste caso, não resolveria o seu problema, visto que o tempo de execução do aggregate não significa nem 10% do tempo de consulta. []'s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] work_mem por requisição
mesma coisa. Eu vou rescreve esta consulta alterando a forma de buscar as informações, utilizando plpgsql e buscando por parte os dados retornando as mesmas informações. O certo, é que temos que mudar a versão do banco e pra isto, vai demorar mais uns meses. Aggregate (cost=21.88..21.97 rows=1 width=42) (actual time=0.719..0.719 rows=1 loops=1) - Nested Loop Left Join (cost=0.00..21.80 rows=1 width=42) (actual time=0.055..0.455 rows=25 loops=1) - Nested Loop Left Join (cost=0.00..19.52 rows=1 width=41) (actual time=0.050..0.326 rows=25 loops=1) * Filter: (NotaFiscal.CodigoNotaMatrizNota IS NULL)* - Index Scan using NotaItem_Empresa_Produto_Data_Situacao_I on NotaItem (cost=0.00..10.89 rows=1 width=41) (actual time=0.036..0.087 rows=25 loops=1) Index Cond: ((CodigoEmpresaItem = 77222) AND (CodigoProdutoItem = 27149) AND (DataMovimentoItem = '2013-12-01'::date) AND (DataMovimentoItem = '2013-12-31'::date)) Filter: (SituacaoNotaItem IS NULL) - Index Scan using NotaFiscal_CodigoInterno_PK on NotaFiscal (cost=0.00..8.62 rows=1 width=12) (actual time=0.006..0.007 rows=1 loops=25) Index Cond: (NotaItem.CodigoNotaItem = NotaFiscal.CodigoInternoNota) - Index Scan using Operacao_CodigoInterno_PK on Operacao (cost=0.00..2.27 rows=1 width=9) (actual time=0.002..0.003 rows=1 loops=25) Index Cond: (NotaFiscal.CodigoOperacaoEstoqueNota = Operacao.CodigoInternoOperacoes) Total runtime: 0.960 ms Marcos André G.A Trabin Softwarre Consulting - www.trabin.com.br *Blog:* http://lgerardlucas.blogspot.com/ *twitter:* http://twitter.com/lgerardlucas Em 31 de janeiro de 2014 09:55, Rafael Fialho Corrêa r.fia...@ibest.com.brescreveu: Em 31 de janeiro de 2014 09:38, Marcos - GMail lgerardlu...@gmail.comescreveu: CREATE INDEX NotaFiscal_CodigoNotaMatrizNota_I ON NotaFiscal USING btree (CodigoNotaMatrizNota ); Não sei se vai adiantar muita coisa, porque vai depender muito da quantidade de registros e do próprio plano de execução, mas tente executar os seguintes comandos e veja se melhora alguma coisa: CREATE INDEX NotaFiscal_CodigoNotaMatrizNota_IsNull_I ON NotaFiscal USING btree (CodigoNotaMatrizNota) WHERE (CodigoNotaMatrizNota IS NULL; analyze NotaFiscal; Creio que aumentar o work_mem, neste caso, não resolveria o seu problema, visto que o tempo de execução do aggregate não significa nem 10% do tempo de consulta. []'s ___ 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] work_mem por requisição
On 31-01-2014 10:16, Marcos - GMail wrote: mesma coisa. Eu vou rescreve esta consulta alterando a forma de buscar as informações, utilizando plpgsql e buscando por parte os dados retornando as mesmas informações. O certo, é que temos que mudar a versão do banco e pra isto, vai demorar mais uns meses. Não faça isso, SQL é declarativo justamente para que você não se preocupe em como os dados serão processados e retornados, e sim apenas em o que vc precisa retornar. Geralmente fazer isso que você propõe pode ser mais problemático do que rever o seu SQL (alias vi não o enviou para que pudessemos ajudar) e também seus índices. Aggregate (cost=21.88..21.97 rows=1 width=42) (actual time=0.719..0.719 rows=1 loops=1) - Nested Loop Left Join (cost=0.00..21.80 rows=1 width=42) (actual time=0.055..0.455 rows=25 loops=1) - Nested Loop Left Join (cost=0.00..19.52 rows=1 width=41) (actual time=0.050..0.326 rows=25 loops=1) * Filter: (NotaFiscal.CodigoNotaMatrizNota IS NULL)* - Index Scan using NotaItem_Empresa_Produto_Data_Situacao_I on NotaItem (cost=0.00..10.89 rows=1 width=41) (actual time=0.036..0.087 rows=25 loops=1) Index Cond: ((CodigoEmpresaItem = 77222) AND (CodigoProdutoItem = 27149) AND (DataMovimentoItem = '2013-12-01'::date) AND (DataMovimentoItem = '2013-12-31'::date)) Filter: (SituacaoNotaItem IS NULL) - Index Scan using NotaFiscal_CodigoInterno_PK on NotaFiscal (cost=0.00..8.62 rows=1 width=12) (actual time=0.006..0.007 rows=1 loops=25) Index Cond: (NotaItem.CodigoNotaItem = NotaFiscal.CodigoInternoNota) - Index Scan using Operacao_CodigoInterno_PK on Operacao (cost=0.00..2.27 rows=1 width=9) (actual time=0.002..0.003 rows=1 loops=25) Index Cond: (NotaFiscal.CodigoOperacaoEstoqueNota = Operacao.CodigoInternoOperacoes) Total runtime: 0.960 ms Enviar sua query nos ajudaria a te ajudar !!! Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] work_mem por requisição
On 31-01-2014 09:51, Fabrízio de Royes Mello wrote: On 31-01-2014 10:16, Marcos - GMail wrote: ... Total runtime: 0.960 ms Enviar sua query nos ajudaria a te ajudar !!! Além disso, menos de 1 ms é muito rápido. Caso essa seja uma base de testes, ajudaria se você apresentasse a consulta e o EXPLAIN ANALYZE na base de produção. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] work_mem por requisição
analyse NotaFiscal
explain analyse
select sum(case when NotaItem.TipoOperacaoItem='S' and
Operacao.TipoOperacoes = 'V' then
NotaItem.QuantidadeItem
else 0 end) as QtdeSaidaVenda,
sum(case when NotaItem.TipoOperacaoItem='S' and
Operacao.TipoOperacoes = 'T' then
NotaItem.QuantidadeItem
else 0 end) as QtdeSaidaTransferencia,
sum(case when NotaItem.TipoOperacaoItem='S' and
Operacao.TipoOperacoes = 'D' then
NotaItem.QuantidadeItem
else 0 end) as QtdeSaidaDevolucao,
sum(case when NotaItem.TipoOperacaoItem='S' and
Operacao.TipoOperacoes = 'O' then
NotaItem.QuantidadeItem
else 0 end) as QtdeSaidaOutros,
sum(case when NotaItem.TipoOperacaoItem='E' and
Operacao.TipoOperacoes = 'C' then
NotaItem.QuantidadeItem
else 0 end) as QtdeEntradaCompra,
sum(case when NotaItem.TipoOperacaoItem='E' and
Operacao.TipoOperacoes = 'T' then
NotaItem.QuantidadeItem
else 0 end) as QtdeEntradaTransferencia,
sum(case when NotaItem.TipoOperacaoItem='E' and
Operacao.TipoOperacoes = 'D' then
NotaItem.QuantidadeItem
else 0 end) as QtdeEntradaDevolucao,
sum(case when NotaItem.TipoOperacaoItem='E' and
Operacao.TipoOperacoes = 'O' then
NotaItem.QuantidadeItem
else 0 end) as QtdeEntradaOutros,
sum(case when NotaItem.TipoOperacaoItem='S' and
Operacao.TipoOperacoes = 'V' then
NotaItem.ValorTotalItem
else 0 end) as TotalSaidaVenda,
sum(case when NotaItem.TipoOperacaoItem='S' and
Operacao.TipoOperacoes = 'T' then
NotaItem.ValorTotalItem
else 0 end) as TotalSaidaTransferencia,
sum(case when NotaItem.TipoOperacaoItem='S' and
Operacao.TipoOperacoes = 'D' then
NotaItem.ValorTotalItem
else 0 end) as TotalSaidaDevolucao,
sum(case when NotaItem.TipoOperacaoItem='S' and
Operacao.TipoOperacoes = 'O' then
NotaItem.ValorTotalItem
else 0 end) as TotalSaidaOutros,
sum(case when NotaItem.TipoOperacaoItem='E' and
Operacao.TipoOperacoes = 'C' then
NotaItem.ValorTotalItem
else 0 end) as TotalEntradaCompra,
sum(case when NotaItem.TipoOperacaoItem='E' and
Operacao.TipoOperacoes = 'T' then
NotaItem.ValorTotalItem
else 0 end) as TotalEntradaTransferencia,
sum(case when NotaItem.TipoOperacaoItem='E' and
Operacao.TipoOperacoes = 'D' then
NotaItem.ValorTotalItem
else 0 end) as TotalEntradaDevolucao,
sum(case when NotaItem.TipoOperacaoItem='E' and
Operacao.TipoOperacoes = 'O' then
NotaItem.ValorTotalItem
else 0 end) as TotalEntradaOutros
FROM NotaItem left join NotaFiscal on CodigoNotaItem
= CodigoInternoNota
left join Operacao on CodigoOperacaoEstoqueNota
= CodigoInternoOperacoes
WHERE NotaItem.CodigoEmpresaItem=77222
AND NotaItem.CodigoProdutoItem=27149
AND NotaItem.DataMovimentoItem between Cast('2013-12-01' as
date) and Cast('2013-12-31' as date)
* --and
to_char(NotaItem.DataMovimentoItem,'mm')=to_char($2,'mm') -
Esta linha eu alterei, utilizando a linha de cima. Com isto, o planejador
usou índice.*
AND NotaItem.SituacaoNotaItem Is Null
AND NotaFiscal.CodigoNotaMatrizNota is Null
Marcos André G.A
Trabin Softwarre Consulting - www.trabin.com.br
*Blog:* http://lgerardlucas.blogspot.com/
*twitter:* http://twitter.com/lgerardlucas
Em 31 de janeiro de 2014 10:51, Fabrízio de Royes Mello
fabri...@timbira.com.br escreveu:
On 31-01-2014 10:16, Marcos - GMail wrote:
mesma coisa. Eu vou rescreve esta consulta alterando a forma de buscar
as informações, utilizando plpgsql e buscando por parte os dados
retornando as mesmas informações. O certo, é que temos que mudar a
versão do banco e pra isto, vai demorar mais uns meses.
Não faça isso, SQL é declarativo justamente para que você não se preocupe
em como os dados serão processados e retornados, e sim apenas em o que
vc precisa retornar.
Geralmente fazer isso que você propõe pode ser mais problemático do que
rever o seu SQL (alias vi não o enviou para que pudessemos ajudar) e também
seus índices.
Aggregate (cost=21.88..21.97 rows=1 width=42) (actual
time=0.719..0.719 rows=1 loops=1)
- Nested Loop Left Join (cost=0.00..21.80 rows=1 width=42) (actual
time=0.055..0.455 rows=25 loops=1)
- Nested Loop Left Join (cost=0.00..19.52 rows=1 width=41)
(actual time=0.050..0.326 rows=25 loops=1)
* Filter: (NotaFiscal.CodigoNotaMatrizNota IS NULL)*
- Index Scan using
NotaItem_Empresa_Produto_Data_Situacao_I on NotaItem
(cost=0.00..10.89 rows=1 width=41) (actual time=0.036..0.087 rows=25
loops=1)
Index Cond: ((CodigoEmpresaItem = 77222) AND
(CodigoProdutoItem = 27149) AND (DataMovimentoItem =
'2013-12-01'::date) AND (DataMovimentoItem = '2013-12-31'::date))
Re: [pgbr-geral] work_mem por requisição
Na verdade, peço desculpa, pois este é o explain analyse quando pressionado pela segunda vez, e ai, já estava em cache e não vi. Marcos André G.A Trabin Softwarre Consulting - www.trabin.com.br *Blog:* http://lgerardlucas.blogspot.com/ *twitter:* http://twitter.com/lgerardlucas Em 31 de janeiro de 2014 11:30, Euler Taveira eu...@timbira.com.brescreveu: On 31-01-2014 09:51, Fabrízio de Royes Mello wrote: On 31-01-2014 10:16, Marcos - GMail wrote: ... Total runtime: 0.960 ms Enviar sua query nos ajudaria a te ajudar !!! Além disso, menos de 1 ms é muito rápido. Caso essa seja uma base de testes, ajudaria se você apresentasse a consulta e o EXPLAIN ANALYZE na base de produção. -- Euler Taveira 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
[pgbr-geral] Recomendações para ambiente em crescimento
Boa tarde Pessoal, No meu ambiente atual de Produção rodam 38 sistemas de clientes distintos, sendo que cada um deles tem um contexto na aplicação e um banco separado, segue abaixo minha configuração: Software: Banco de dados (01 servidor): - Versão PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit - Customizações no postgresql.conf max_connections = 200 shared_buffers = 7680MB work_mem = 58MB maintenance_work_mem = 1500MB effective_cache_size = 15360MB checkpoint_segments = 32 checkpoint_timeout = 15min max_locks_per_transaction = 512 - Sistema Operacional: CentOS release 6.4 (Final) - Kernel: 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux - Sistema de arquivos: S.O (ext4 - defaults,noatime), pgsql/9.2/data (ext4 - defaults,noatime), pg_xlog (ext3 - defaults,noatime,data=writeback) e backup (ext4 - defaults,noatime) - Temos bancos de tamanhos distintos variando entre 800MB e 10 GB, no total temos 37 GB; Servidores de aplicação (Entre 01 e 04 - são iniciados sob demanda, dependendo do uso de CPU): - Versão Apache Tomcat/6.0.36.0 - Pool de conexão implementado pela aplicação web - Sistema Operacional: CentOS release 6.4 (Final) - Kernel: 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux - Sistema de arquivos: S.O (ext4 - defaults,noatime), Aplicação (ext4 - defaults,noatime) Hardware: Servidor de banco: CPU: 2 x Xeon Quad Core HT - 2.6 GHz Memória: 30 GB Discos dedicados para S.O (RAID 1), pgsql/9.2/data (RAID 5), pg_xlog (RAID 0) e backup (RAID 1) Servidor de aplicação: CPU: 2 x Xeon Dual Core HT - 2.0 GHz Memória: 15 GB Discos dedicados para S.O (RAID 1), Aplicação (RAID 1) Estamos com previsão de entrada de mais 10 ou 15 clientes nos próximos 02 meses, nesse caso ficaríamos com algo em torno de 50 clientes, e devido a isso eu precisaria mais uma vez subir o numero do max_connections para 250 ou 300, hoje raramente temos reclamações de performance no banco a não ser em casos de locks gerados por problemas na própria aplicação. Minha dúvida é (Ufa até que enfim...): O que os senhores me recomendariam para este ambiente em termos de melhorias? Será que esse aumento no max_connections poderá ter impactos na performance? Seria o caso de colocar um segundo servidor de banco para replicação e balanceamento de carga? Se sim qual seria o tipo de replicação recomendada? Muito obrigado pela paciência de ler isso tudo até o final e desculpem de esqueci de citar algo importante. Um abraço, Nildo Abreu ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Recomendações para ambiente em crescimento
O que os senhores me recomendariam para este ambiente em termos de melhorias? 1) Que ele seja bem monitorado. 2) Com uma quantidade crítica de clientes dessa, que você estude muito e seja sempre ativo em nossa comunidade. 3) Use a lista com perguntas mais diretas e pontuais. Perguntar em geral onde posso melhorar soa como me dá uma consultoria aí? Será que esse aumento no max_connections poderá ter impactos na performance? Sem sombra de dúvidas. Seria o caso de colocar um segundo servidor de banco para replicação e balanceamento de carga? Depende se sua aplicação saberá fazer balanceamento de carga com o PostgreSQL. O que você precisa mesmo é usar um PgBouncer pra limitar o consumo de conexões, vide discussão já realizada esta semana na lista (e que o colega que pediu ajuda nem disse se testou e se deu certo, infelizmente) Se sim qual seria o tipo de replicação recomendada? Use a replicação nativa para fins de alta disponibilidade / redundância em caso de falhas. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Recomendações para ambiente em crescimento
O que os senhores me recomendariam para este ambiente em termos de melhorias? 1) Que ele seja bem monitorado. Boa dica, temos investido bastante nisso. 2) Com uma quantidade crítica de clientes dessa, que você estude muito e seja sempre ativo em nossa comunidade. Com certeza, tentarei participar mais.. 3) Use a lista com perguntas mais diretas e pontuais. Perguntar em geral onde posso melhorar soa como me dá uma consultoria aí? Não foi essa a minha intenção, desculpe! Era mais no intuito de caso exista algum erro grave/gritante nas configurações que os Senhores pudessem me mostrar. Será que esse aumento no max_connections poderá ter impactos na performance? Sem sombra de dúvidas. Seria o caso de colocar um segundo servidor de banco para replicação e balanceamento de carga? Depende se sua aplicação saberá fazer balanceamento de carga com o PostgreSQL. O que você precisa mesmo é usar um PgBouncer pra limitar o consumo de conexões, vide discussão já realizada esta semana na lista (e que o colega que pediu ajuda nem disse se testou e se deu certo, infelizmente) Tentei usar PgBoucer antes porém não tive bons resultados, segue abaixo minha configuração utilizada: pool_mode = session max_client_conn = 200 default_pool_size = 20 Para clientes que tem muitos acessos aumentei o pool_size para 30 ou 40, porém aconteceu algumas vezes de travar a aplicação e ficar mais de 30 conexões em maxwait, fiz alguma besteira nessa configuração? Se sim qual seria o tipo de replicação recomendada? Use a replicação nativa para fins de alta disponibilidade / redundância em caso de falhas. Pgpool seria recomendado para usar junto da replicação nativa? ___ 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] Recomendações para ambiente em crescimento
Também seria possível limitar a quantidade de conexões por Database, conforme mostra no manual do postgres. http://www.postgresql.org/docs/9.1/static/sql-alterdatabase.html. ALTER DATABASE name [ [ WITH ] option [ ... ] ] where option can be: CONNECTION LIMIT connlimit Desta forma, seria possível controlar melhor as conexões para databases mais acessados. []s Em 31 de janeiro de 2014 14:50, Nildo Abreu nildoab...@gmail.com escreveu: Boa tarde Pessoal, No meu ambiente atual de Produção rodam 38 sistemas de clientes distintos, sendo que cada um deles tem um contexto na aplicação e um banco separado, segue abaixo minha configuração: Software: Banco de dados (01 servidor): - Versão PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit - Customizações no postgresql.conf max_connections = 200 shared_buffers = 7680MB work_mem = 58MB maintenance_work_mem = 1500MB effective_cache_size = 15360MB checkpoint_segments = 32 checkpoint_timeout = 15min max_locks_per_transaction = 512 - Sistema Operacional: CentOS release 6.4 (Final) - Kernel: 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux - Sistema de arquivos: S.O (ext4 - defaults,noatime), pgsql/9.2/data (ext4 - defaults,noatime), pg_xlog (ext3 - defaults,noatime,data=writeback) e backup (ext4 - defaults,noatime) - Temos bancos de tamanhos distintos variando entre 800MB e 10 GB, no total temos 37 GB; Servidores de aplicação (Entre 01 e 04 - são iniciados sob demanda, dependendo do uso de CPU): - Versão Apache Tomcat/6.0.36.0 - Pool de conexão implementado pela aplicação web - Sistema Operacional: CentOS release 6.4 (Final) - Kernel: 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux - Sistema de arquivos: S.O (ext4 - defaults,noatime), Aplicação (ext4 - defaults,noatime) Hardware: Servidor de banco: CPU: 2 x Xeon Quad Core HT - 2.6 GHz Memória: 30 GB Discos dedicados para S.O (RAID 1), pgsql/9.2/data (RAID 5), pg_xlog (RAID 0) e backup (RAID 1) Servidor de aplicação: CPU: 2 x Xeon Dual Core HT - 2.0 GHz Memória: 15 GB Discos dedicados para S.O (RAID 1), Aplicação (RAID 1) Estamos com previsão de entrada de mais 10 ou 15 clientes nos próximos 02 meses, nesse caso ficaríamos com algo em torno de 50 clientes, e devido a isso eu precisaria mais uma vez subir o numero do max_connections para 250 ou 300, hoje raramente temos reclamações de performance no banco a não ser em casos de locks gerados por problemas na própria aplicação. Minha dúvida é (Ufa até que enfim...): O que os senhores me recomendariam para este ambiente em termos de melhorias? Será que esse aumento no max_connections poderá ter impactos na performance? Seria o caso de colocar um segundo servidor de banco para replicação e balanceamento de carga? Se sim qual seria o tipo de replicação recomendada? Muito obrigado pela paciência de ler isso tudo até o final e desculpem de esqueci de citar algo importante. Um abraço, Nildo Abreu ___ 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] RES: Postgre embarcado? é Possivel?
Em 30 de janeiro de 2014 09:39, Rodrigo rodrigo.ina...@alcafoods.comescreveu: Então! Se eu resolvesse vender o sistema na caixa e o cliente mesmo instalar se possível queria que o cara clicasse em instalar e não perguntasse nada das opções do postgres pra ele... Rodrigo Não seria melhor colocar o PG como pré-requisito (como o Windows, por exemplo) e deixar por conta dele instalar o PostgreSQL? O seu instalador poderia pedir o IP do servidor + senha do usuário postgres, conectar, verificar os parâmetros (e abortar se for o caso), criar usuários, BD, estrutura, etc. -- Atenciosamente, Alexsander da Rosa ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Recomendações para ambiente em crescimento
Também seria possível limitar a quantidade de conexões por Database, conforme mostra no manual do postgres. http://www.postgresql.org/docs/9.1/static/sql-alterdatabase.html. ALTER DATABASE name [ [ WITH ] option [ ... ] ] where option can be: CONNECTION LIMIT connlimit Desta forma, seria possível controlar melhor as conexões para databases mais acessados. Obrigado Vinícius!!! []s Em 31 de janeiro de 2014 14:50, Nildo Abreu nildoab...@gmail.comescreveu: Boa tarde Pessoal, No meu ambiente atual de Produção rodam 38 sistemas de clientes distintos, sendo que cada um deles tem um contexto na aplicação e um banco separado, segue abaixo minha configuração: Software: Banco de dados (01 servidor): - Versão PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit - Customizações no postgresql.conf max_connections = 200 shared_buffers = 7680MB work_mem = 58MB maintenance_work_mem = 1500MB effective_cache_size = 15360MB checkpoint_segments = 32 checkpoint_timeout = 15min max_locks_per_transaction = 512 - Sistema Operacional: CentOS release 6.4 (Final) - Kernel: 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux - Sistema de arquivos: S.O (ext4 - defaults,noatime), pgsql/9.2/data (ext4 - defaults,noatime), pg_xlog (ext3 - defaults,noatime,data=writeback) e backup (ext4 - defaults,noatime) - Temos bancos de tamanhos distintos variando entre 800MB e 10 GB, no total temos 37 GB; Servidores de aplicação (Entre 01 e 04 - são iniciados sob demanda, dependendo do uso de CPU): - Versão Apache Tomcat/6.0.36.0 - Pool de conexão implementado pela aplicação web - Sistema Operacional: CentOS release 6.4 (Final) - Kernel: 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux - Sistema de arquivos: S.O (ext4 - defaults,noatime), Aplicação (ext4 - defaults,noatime) Hardware: Servidor de banco: CPU: 2 x Xeon Quad Core HT - 2.6 GHz Memória: 30 GB Discos dedicados para S.O (RAID 1), pgsql/9.2/data (RAID 5), pg_xlog (RAID 0) e backup (RAID 1) Servidor de aplicação: CPU: 2 x Xeon Dual Core HT - 2.0 GHz Memória: 15 GB Discos dedicados para S.O (RAID 1), Aplicação (RAID 1) Estamos com previsão de entrada de mais 10 ou 15 clientes nos próximos 02 meses, nesse caso ficaríamos com algo em torno de 50 clientes, e devido a isso eu precisaria mais uma vez subir o numero do max_connections para 250 ou 300, hoje raramente temos reclamações de performance no banco a não ser em casos de locks gerados por problemas na própria aplicação. Minha dúvida é (Ufa até que enfim...): O que os senhores me recomendariam para este ambiente em termos de melhorias? Será que esse aumento no max_connections poderá ter impactos na performance? Seria o caso de colocar um segundo servidor de banco para replicação e balanceamento de carga? Se sim qual seria o tipo de replicação recomendada? Muito obrigado pela paciência de ler isso tudo até o final e desculpem de esqueci de citar algo importante. Um abraço, Nildo Abreu ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgre embarcado? é Possivel?
Você poderia usar o programa InstallShield ou *InnoSetup *para Windows, ele faz o empacotamento e cria um executável de instalação. Você pode tentar essa possibilidade. Quando trabalhei na prefeitura, o CAD ÚNICO - programa que controla o bolsa família - vinha com um instalador que instalava e configurava o Postgresql automaticamente, com apenas algumas clique e configurações avançadas se necessário. O mesmo executável instalava no cliente quanto no server. []s Em 30 de janeiro de 2014 16:49, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2014-01-30 Tiago Adami adam...@gmail.com: Conheço mais de um projeto que falhou ao tentar adiantar o lado do cliente com PostgreSQL embarcado (instalado automaticamente). Certo, mas creio que amiúde é falta de entender a miríade de decisões que estão embutidas num sistema embarcado, para as quais o SQLite já vem pronto, por exemplo. Talvez Firebird ou SQLite não atendem a sua necessidade? SQLite, sem dúvida. Mantém melhor a compatibilidade tanto com o PostgreSQL quanto com o ISO SQL e outros sistemas. A razão? O desenvolvedor principal usa a documentação do PostgreSQL como referência (ou intermediário) para o ISO SQL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgre embarcado? é Possivel?
2014-01-30 Rodrigo rodrigo.ina...@alcafoods.com: Bom dia Pessoal! Tem como usar o postgres embarcado numa aplicação java? Pelo menos que o instalador já instale o .jar e o banco? Rodrigo se quer algo altamente embarcado então pode ser que o sqlite resolva seu problema. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
Em 30 de janeiro de 2014 15:02, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Mais uma dúvida, estamos com o Postgres rodando em uma máquina virtual, teríamos mais desempenho se estivéssemos rodando em uma máquina física com as mesmas configurações? Não sequestre a thread. Isso é outro assunto, não relacionado à sua primeira pergunta. Todavia, a resposta é *depende*. Hoje pode-se fazer ótimos servidores de bancos de dados virtuais, principalmente com umas máquinas gigantes que andam vendendo por aí (centenas de CPUs e terabytes de memória). Pra fazer uma cola com o assunto origila, isso não muda o fato de que você está abrindo conexões demais ao banco. Físico ou virtual, é conexão demais. Você tem a faca (PgBouncer) e o queijo (PostgreSQL) na mão. É só cortar (diminuir o número de conexões ao banco, nas configurações do PgBouncer). E conte pra nós seu sucesso daqui a pouco. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Olá colegas, depois de vários testes, deixamos o PgBoucer passando 22 conexões para o PostgreSql. Passamos a ter melhor resposta mesmo. Com o teste de 500 users no Jmeter, o banco responde bem no PgAdmin, porém a aplicação web fica um pouco lenta. Abs. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como resolver alta demanda de conexoes
depois de vários testes, deixamos o PgBoucer passando 22 conexões para o PostgreSql. Passamos a ter melhor resposta mesmo. Com o teste de 500 users no Jmeter, o banco responde bem no PgAdmin, porém a aplicação web fica um pouco lenta. Fico feliz que tenha evoluído com seus resultados! Agora é hora de tirar o segundo truque da cartola do PgBouncer: crie mais um banco de dados virtual apontando pro mesmo banco real, e aponte sua aplicação web para esse banco separado. Assim, você terá uma fila exclusiva para a aplicação web, que certamente tem perfil diferente da outra, e você pode controlar quantas conexões vai reservar pra cada lado. Tente e conte pra nós. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
