Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

[Matheus de Oliveira]

On Fri, Jun 2, 2017 at 3:00 PM, Alexsander Rosa <alexsander.r...@gmail.com>
wrote:

> laboratorio:rnge2=# *EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
> sp_teste('4317060556386800011365701004061895261728');*
> QUERY PLAN
>
> 
> --
>  Result  (cost=0.00..0.04 rows=1 width=0) (actual time=1494.473..1494.473
> rows=1 loops=1)
>Buffers: shared hit=18939 read=123331
>  Total runtime: 1494.496 ms
> (3 rows)
>

Isso aí pra mim tá com cara de plano de execução genérico. Mas pra ter
certeza seria legal você instalar e habilitar o auto_explain, daí você
configura `auto_explain.log_nested_statements = on`  e executa a função
novamente, ele vai logar o plano de execução só daquela consulta no log.

Se quiser dá pra fazer na sua sessão direto:

postgres=# LOAD 'auto_explain';
LOAD
postgres=# SET auto_explain.log_analyze TO on;
SET
postgres=# SET auto_explain.log_min_duration TO 0;
SET
postgres=# SET auto_explain.log_nested_statements TO on;
SET
postgres=# SET client_min_messages TO log;
SET
postgres=# SELECT
sp_teste('4317060556386800011365701004061895261728');
    ...  ...


Atenciosamente,

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

Re: [pgbr-geral] ORDER BY errado

[Matheus de Oliveira]

2016-12-15 14:56 GMT-02:00 Sebastian Webber <sebast...@swebber.me>:

> Dá uma olhada nesse post[1] e depois me comenta as configurações de
> collate.
>
> [1] http://swebber.me/blog/2013/05/16/corrigindo-
> problema-ordenacao-postgresql-rhel6/
>

Ao fazer isso é necessário executar um REINDEX de todos os índices que usam
esse COLLATE (basicamente todos os tipos textuais, a não ser que usem
explicitamente outro COLLATE), se não pode trazer resultados incorretos em
alguns casos.

Acho que seria bom adicionar essa informação no post, Seba.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tamanho real da base em disco

[Matheus de Oliveira]

2016-12-16 8:25 GMT-02:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:

> O dobro do tamanho aparece quando executo o comando select
> pg_size_pretty(pg_database_size('teste2'));
>
> Neste comando ele calcula fisicamente o tamanho e conta os 2 diretórios?
> Pra mim isso é novidade (e não estou sendo ironico k), eu realmente
> achei que essa função calculava o tamanho da base logicamente.
>

Essa função é bem simples, faz uma busca em todo tablespace pelo diretório
com OID do banco e no base/OID, depois navega em cada diretório que achar e
soma o tamanho (a função db_dir_size, abaixo, que faz isso), veja:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/utils/adt/dbsize.c;hb=HEAD#l79

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PG Restore demorando muito

[Matheus de Oliveira]

2016-11-22 9:09 GMT-02:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:

> Mas com o PJE o -J não adianta muito, de 2 pra cima fica tudo igual por
> causa das tabelas de binários que são bem maiores que as outras.
> Nossa base está em 400GB e tivemos essa característica.
>

Só por curiosidade, empre que ouço do PJE vejo que salvar dados binários em
banco é a maior reclamação e o que gera mais trabalho na administração
dessa aplicação (nunca usei, então pode ser só impressão minha). Eles não
têm nenhum plano pra eliminar isso e salvar arquivos binários num
filesystem?

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] monitoramento usando Trigger

[Matheus de Oliveira]

2016-11-20 18:40 GMT-02:00 Neto pr <neto...@gmail.com>:

> Eu sei que teria como fazer por tabela (exemplo abaixo), mas eu
> preciso que seja para qualquer comando DML. Se tivesse como em vez de
> nome_tabela colocar all_tables algo assim
>

Não dá, mas você pode criar apenas uma função genérica (que funcione com
qualquer tabela), depois adicionar uma trigger em cada tabela (pode até
usar o catálogo pra gerar o comando CREATE TRIGGER).

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PG Restore demorando muito

[Matheus de Oliveira]

2016-11-18 9:45 GMT-02:00 Marcell Ribeiro <marcell.ribe...@gmail.com>:

> /usr/local/bin/pg_restore -U usuario -d banco -v
> /disco1/backup_andamento.tar
>
> Já testei com -j e sem, não vi diferença nenhuma. Não uso compressão
> durante o dump por que li que algumas vezes pode dar problema.
>

Que problema? Compressão é bem tranquilo pra dump.

Uma coisa que eu recomendo mudar é o formato, usar custom (ou directory) ao
invés de tar. O formato tar na minha opinião é bem ruim e devia ser
removido.

Quanto à configurações, veja [1]. Tente identificar também em que ponto é
mais lento, se no COPY vai rápido mas na criação de índices e constraints é
lento, então aumentar o maintenance_work_mem vai ajudar bastante, tunning
de CHECKPOINT/WAL ajuda bastante também.

Se estiver engargalando no processo de checkpoint, por exemplo, aumentar o
número de jobs pode mesmo piorar.

[1]
https://www.postgresql.org/docs/current/static/populate.html#POPULATE-PG-DUMP

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Função com generate_series

[Matheus de Oliveira]

2016-10-19 9:41 GMT-02:00 Izaque Maciel <izaquemac...@gmail.com>:

> encontrei também uma maneira de atualizá-las, em alguns casos de rollback.


Essa afirmação me deixa um tanto preocupado, você não está falando de
executar um SETVAL após um ROLLBACK, né?


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

Re: [pgbr-geral] Função com generate_series

[Matheus de Oliveira]

2016-10-19 8:45 GMT-02:00 Izaque Maciel <izaquemac...@gmail.com>:

> Obrigado Mateus, farei os ajustes. Só mais uma dúvida, utilizando a
> sequence mencionada acima ou o nextval explícito, nunca ocorrerá problemas
> de concorrência?


Não, porque o PostgreSQL garante que apenas uma sessão recupere o mesmo
valor na sequence.

Um efeito causado pela sequence, entretanto, é que em caso de ROLLBACK da
transação o valor da sequence não volta, podendo deixar buracos na
sequência. O que em geral não é um problema, porque o que sequence garante
é só a geração de valores únicos.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Função com generate_series

[Matheus de Oliveira]

On Tue, Oct 18, 2016 at 3:19 PM, Izaque Maciel <izaquemac...@gmail.com>
wrote:

>   FOR rec IN
> select date
> from generate_series(new.dtinicial::timestamp,
>   new.dtfinal, '1 day') date
> where extract(dow from date) not in (0,6)
>   LOOP
> INSERT INTO tarefa_itens (id, id_tarefaag, data_horafin,
>  data_horaexec, executada)
> VALUES ((select coalesce((max(ti.id) + 1), 1)
> chave from tarefa_itens ti),
>   new.id,
>   null,
> rec.date   -- Aqui
>   'N');
>
>   END LOOP;
>

Além do que o Euler já comentou, eu tenho mais duas recomendações.

1. Essa é bem grave, usar `select coalesce(max(id)+1),1) ...` é uma prática
comum, mas pode ter consequências indesejáveis devido à problemas de
concorrência. Interessante que comentei sobre isso esses dia no último
PGDay Campinas [1]. Caso duas sessões tentem executar esse código ao mesmo
tempo, ambas vão recuperar o mesmo ID, tentando assim inserir o mesmo
valor. A solução nesse caso é simplesmente usar uma SEQUENCE, para isso
basta definir a coluna ID como SERIAL ou BIGSERIAL e simplesmente não usar
essa coluna no INSERT, deixando o PostgreSQL gerar o ID automaticamente (ou
então use DEFAULT ou nextval explícito).

2. Essa não é um problema, é mais uma pequena otimização. Eu também não
usaria LOOP, simplesmente faria INSERT ... SELECT.

O resultado seria mais ou menos assim:

INSERT INTO tarefa_itens (
id_tarefaag, data_horafin, data_horaexec, executada
)
SELECT
NEW.id, null, g.dt, 'N'
FROM
generate_series(new.dtinicial::timestamp, new.dtfinal, '1 day') AS
g(dt)
WHERE
EXTRACT(DOW FROM g.dt) NOT IN (0,6);

Se quiser fazer o equivalente ao SERIAL na coluna que já existe, basta
executar:

BEGIN;
CREATE SEQUENCE tarefa_itens_id_seq;
ALTER TABLE tarefa_itens ALTER id SET DEFAULT
nextval('tarefa_itens_id_seq');
ALTER SEQUENCE tarefa_itens_id_seq OWNED BY tarefa_itens.id;
SELECT setval('tarefa_itens_id_seq', max(id)) FROM tarefa_itens;
COMMIT;

[1]
http://www.slideshare.net/matheus_de_oliveira/o-que-voc-acha-que-sabe-sobre-banco-de-dados

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] erro de conexão

[Matheus de Oliveira]

2016-10-15 7:54 GMT-03:00 Antonio Silva <aolinto@gmail.com>:

> Ver Cluster Port Status OwnerData directory   Log file
> 9.5 main5432 down   postgres /var/lib/postgresql/9.5/main
> /var/log/postgresql/postgresql-9.5-main.log
>

O banco sobe depois de executar o comando que segue?

$ sudo pg_ctlcluster 9.5 main start

Se não subir, o que aparece (últimas linhas) no arquivo de logo
(/var/log/postgresql/postgresql-9.5-main.log) ?

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

Re: [pgbr-geral] Ajuda com SQL

[Matheus de Oliveira]

2016-10-14 10:04 GMT-03:00 Ricardo <rica...@longomaquinas.com>:

> Como posso acrescentar um campo denominado  “Valor_Atual” onde vai ser
> somado os valores do “Valor_Mes” que antecederem o “Mes” corrente ?


Você pode simplesmente usar window functions [1] para isso:

SELECT
"Referencia",
"Ano",
"Valor_Mes",
"Mes",
SUM("Valor_Mes") OVER(ORDER BY "Mes") AS "Valor_Parcial"
FROM (

) t
ORDER BY t."Mes";

Uma dica é usar '01', '02', ... para o mês ao invés de '1', '2', ..., assim
mantém a ordenação mesmo com string (de fato eu prefiro referenciar ano/mês
como Date, sendo o componente de dia com o primeiro dia do mês).

[1] http://dextra.com.br/pt/window-functions-no-postgresql-parte1/

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

Re: [pgbr-geral] Obter menor valor de coluna - Dúvida sobre index only scan em tabela/índice grande

[Matheus de Oliveira]

2016-09-30 16:52 GMT-03:00 Everton Luís Berz <everton.b...@gmail.com>:

> Ambas realizam um index only scan e levam em torno de 10 minutos pra
> terminar.


hm... Sério? Bem estranho isso mesmo, eram pra ser consultas quase
instantâneas, mesmo com bilhões de linhas na tabela. E ambas têm uma
execução bem semelhante, duvido que encontrará diferença de performance
entre uma e outro (ao menos nas versões mais recentes).

Se está lento assim, a única explicação que vem à minha cabeça é um inchaço
bem grande nesse índice, se for o caso um REINDEX (ou criar um novo índice,
assim pode usar o CONCURRENTLY) deve resolver. Pode testar?

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Erro ao executar vários deletes

[Matheus de Oliveira]

On Fri, Sep 30, 2016 at 2:28 PM, <bruno@yahoo.com> wrote:

> ERROR:  permission denied for schema transporte LINE 1: SELECT 1 FROM ONLY
> "transporte"."anexo_movimento_veiculo" x ...^
> QUERY:  SELECT 1 FROM ONLY "transporte"."anexo_movimento_veiculo" x WHERE
> $1 OPERATOR(pg_catalog.=) "id_movimento_veiculo" FOR KEY SHARE OF x
> CONTEXT:  SQL statement "delete from transporte.movimento_veiculo mv2 where
> mv2.id_movimento_veiculo= movimento_veiculo[i]" PL/pgSQL function
> inline_code_block line 38 at SQL statement


É, acho que essa não é muito intuitiva mesmo... Vou tentar explicar.

Esse erro acontece quando você executa o DELETE na tabela "
transporte.movimento_veiculo", e certamente há uma chave estrangeira da
tabela "anexo_movimento_veiculo" para a "movimento_veiculo", certo? Bem,
para verificar se o DELETE que você executou não fere essa *constraint* (ou
seja, se não está deletando um "movimento_veiculo" que ainda é referenciado
em "anexo_movimento_veiculo"), o PostgreSQL executa o SELECT que você vê aí:

SELECT 1 FROM ONLY "transporte"."anexo_movimento_veiculo" x
WHERE $1 OPERATOR(pg_catalog.=) "id_movimento_veiculo"
FOR KEY SHARE OF x

Sendo "$1" o valor que está sendo excluído pela PK (ou uma UK) de "
movimento_veiculo".

Mas, veja que esse SELECT é executado internamente pelo PostgreSQL (a
maioria das pessoas nem sabe que é um SELECT que é feito para verificar
FK), e essa consulta só existe porque há uma chave estrangeira na tabela "
anexo_movimento_veiculo" (que esse *owner* é responsável por ela), isso
significa que o proprietário/*owner* dessa tabela é quem está forçando essa
restrição, logo esse mesmo proprietário/*owner* deve ter permissão de
executar esse SELECT acima, assim sendo o PostgreSQL faz essa consulta como
se estivesse logado com esse usuário.

Ou seja, a solução do seu problema é:

1. Veja qual o *owner* da "anexo_movimento_veiculo"
2. Adicione permissão necessária. Por exemplo:
GRANT USAGE ON SCHEMA transporte TO ;
3. Teste novamente, e se der algum erro nos avise aqui, pode ter mais
alguma permissão faltando.

Meio chatinho essa parte, fui claro?

Pode perguntar aí se tiver alguma dúvida.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Mudanças no repositório do PGDG

[Matheus de Oliveira]

2016-09-29 14:15 GMT-03:00 Sebastian Webber <sebast...@swebber.me>:

> Imagino que os servidores baseados no Debian sofram do mesmo mal.


Pelo que entendi essas mudanças foram só nos repositórios yum/rpm mesmo.


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

Re: [pgbr-geral] Tabela não aceita criação de trigger

[Matheus de Oliveira]

2016-09-20 10:47 GMT-03:00 Alessandro Lima <grandegoia...@gmail.com>:

> rodei o comando: select database, gid, prepared from pg_prepared_xacts
> e nele o campo prepared mostrava data de fevereiro de 2016
> executei o comando: rollback prepared '4871251_
> EF6eOp5vdGltaXplLXBjLHNlcnZlcixQMTAw_b3RpbWl6ZS1wYyxzZXJ2ZXIsUDEwMCwB'
> e resolveu o problema, trigger criada com sucesso.
>

Cara, se está usando 2PC (two phase commit) tome muito cuidado, uma
transação aberta assim há tanto tempo pode te dar muita dor de cabeça
(coisas bem piores do que esse lock podem acontecer). Você precisa
urgentemente criar um monitoramento pra verificar transações preparadas que
não foram finalizadas há muito tempo.

Um SELECT simples como:

SELECT age(now(), max(prepared)) FROM pg_prepared_xacts;

já é bom para monitorar (ao menos para ser alertado).

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT lento

[Matheus de Oliveira]

digo_empresa
>

Olhando a consulta, você faz um UNION ALL do que é a praticamente a mesma
consulta, seria melhor se pudesse separar as colunas e ter o resultado da
consulta como (codigo_empresa, codigo_anterior, mes01_entrada, mes01_saida,
mes02_entrada, mes02_saida, etc.), é viável nesse formato? Se não for, pode
ainda sim gerar dessa forma e usar um truquezinho com array e unnest para
fazer o equivalente à um UNPIVOT:

SELECT
tmp.codigo_empresa, tmp.codigo_anterior,
unnest(array['Entrada', 'Saida']) AS tipo,
unnest(array[tmp.mes01_entrada, tmp.mes01_saida]) AS
quantidade_mes01,
unnest(array[tmp.mes02_entrada, tmp.mes02_saida]) AS
quantidade_mes02,
...
FROM (
SELECT
its.codigo_empresa,
ite.codigo_anterior,
SUM(CASE WHEN its.mes_ref = '102015' THEN
(its.quantidade_entrada / un.quantidade) ELSE 0 END) AS mes01_entrada,
SUM(CASE WHEN its.mes_ref = '102015' THEN (its.quantidade_saida
/ un.quantidade) ELSE 0 END) AS mes01_saida,
SUM(CASE WHEN its.mes_ref = '112015' THEN
(its.quantidade_entrada / un.quantidade) ELSE 0 END) AS mes02_entrada,
SUM(CASE WHEN its.mes_ref = '112015' THEN (its.quantidade_saida
/ un.quantidade) ELSE 0 END) AS mes02_saida,
...
) AS tmp

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT lento

[Matheus de Oliveira]

On Wed, Sep 21, 2016 at 5:20 PM, Antonio Cesar <cgcesarsoa...@gmail.com>
wrote:

> Segue link:
> https://explain.depesz.com/s/EY6v
>

Pelo que vi por cima no plano, índice em (codigo_item, ano_ref) nas suas
tabelas ajudaria:

CREATE INDEX ON item_mensal (codigo_item, ano_ref);
CREATE INDEX ON item_mensal_2016 (codigo_item, ano_ref);

Pode testar com esses índices por favor e ver se ajuda? Poste o EXPLAIN
ANALYZE da consulta com os índices novamente para análise.


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

Re: [pgbr-geral] archive_command com 2 ou mais comandos

[Matheus de Oliveira]

On Jul 29, 2016 15:34, "Vinícius Aquino do Vale" 
wrote:
>
> Luiz,
>
> Vc pode enviá-lo como parâmetros.
>
> archive_command = 'script.sh  /var/lib/pgsql/9.3/data/%p   /backup/wal/%f
   /backup/walmaster/%f'
>
> $1 - Seria o /var/lib/pgsql/9.3/data/%p

Recomendo utilizar apenas o "%p" no caminho de origem, com isso o script
funcionará mesmo que troque o caminho do PGDATA. Desde que não faça um "cd"
no script, tranquilo.

> $2 - Seria o /backup/wal/%f
> $3 - Seria o /backup/walmaster/%f

Ok.

Um problema do script (além do "mv") é que não faz o retorno correto do
código (exit).

Poderia fazer algo assim:

#!/bin/sh
cp "$1" "$2"
ret1=$?
cp "$1" "$3"
ret2=$?
if [ $ret1 -ne 0 ]; then
echo "erro no 1"
fi
if [ $ret2 -ne 0]; then
echo "erro no 2"
fi
ret=$(( $ret1 + $ret2 ))
exit $ret
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida Trigger

[Matheus de Oliveira]

On Jul 27, 2016 07:46, "Felipe Rigotti -SBsistemas" <
fel...@sbsistemas.com.br> wrote:
>
> a ideia inicial seria não alterar a "principal" (tab_a)

Então explique melhor seu problema, porque eu tinha entendido que era
exatamente o que você queria fazer. Talvez seu exemplo tenha ficado
genérico demais, "XY problem".
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida Trigger

[Matheus de Oliveira]

2016-07-26 13:29 GMT-03:00 Felipe Rigotti [SBSistemas] <
fel...@sbsistemas.com.br>:

> CREATE FUNCTION fnc_tgr_tab_a_upd (
>
> )
>
> RETURNS trigger AS
>
> $body$
>
> DECLARE chave_tabb integer;
>
> BEGIN
>
> insert into tab_b(campo4) values(new.campo1) returning
> campo3 into chave_tabb;
>
>return new;
>
> END;
>
> $body$
>
> LANGUAGE 'plpgsql'
>
> VOLATILE
>
> CALLED ON NULL INPUT
>
> SECURITY INVOKER;
>
>
>
> CREATE TRIGGER tab_a_tr
>
>   AFTER UPDATE
>
>   ON public.tab_a FOR EACH ROW
>
>   EXECUTE PROCEDURE fnc_tgr_tab_a_upd();
>
>
>
> update tab_a set campo2='z' where campo1=1
>

Você quer alterar na própria linha que foi atualizada, certo?

Se sim, ao invés de usar AFTER, use BEFORE e faça:


insert into tab_b(campo4) values(new.campo1) returning campo3 into
chave_tabb;
new.campos2 := chave_tabb;
return new;

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

Re: [pgbr-geral] Monitorando wal_files 9.2

[Matheus de Oliveira]

2016-07-06 18:27 GMT-03:00 Lucas Possamai <drum.lu...@gmail.com>:

> Como posso monitorar isso na versão 9.2?
> Vocês tem alguma dica?
>

1. Verifique nos logs do PostgreSQL, em caso de falhas é alarmado lá;
2. Faça com que seu script envie algum tipo de alerta em caso de falha (não
é 100% seguro, o script pode falhar antes do alerta por algum motivo, volte
no [1]);
3. Monitore a quantidade/espaço de logs na pg_xlog, e alerte caso tenha um
acumulo fora do normal, pois quando o archive falha os segmentos ficam
nesse diretório.

Idealmente implemente as 3 opções... ;)

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_basebackup - 9.3

[Matheus de Oliveira]

2016-07-06 18:07 GMT-03:00 Patrick B <patrickbake...@gmail.com>:

> Então a ideia é realizar o pg_basebackup ao mesmo tempo com o SPLIT.
> Criando assim vários arquivos de 50GB, por exemplo. E depois enviar estes
> arquivos para o novo servidor via rsync.
>
>

Entendi. Faz sentido pra mim. Até porque já dá pra ir mandando os primeiros
antes de gerar todos.


> [...]
>>
>
> Putz Sério que é só da 9.4??? Eu estou usando o 9.2 (Sim, iremos
> atualizar mas vai demorar um pouco :P)
>
> Então o archive vai ter que ser do master?
>
>
Sim, ou pg_receivexlog (esse já funciona na 9.2, se não me engano). Eu
pegaria do master mesmo, por facilidade.


> Mas eu consigo fazer replicação cascade né? Fazer um servidor slave
> replicar de outro slave? Só o archive que não?
>
>

Sim. Sim. E sim.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_basebackup - 9.3

[Matheus de Oliveira]

2016-07-06 0:17 GMT-03:00 Patrick B <patrickbake...@gmail.com>:

> pg_basebackup -Ft -D - -P -v -U replicator -h 127.0.0.1 | split -b 10G
>
>
>
Eu não usuária o -h, melhor ir via Unix domain sockets (não deve ter
*grandes* ganhos, mas creio que seja um pouquinho melhor).

O seu split seria pra poder fazer o upload em paralelo, certo? Tem uma
ferramenta que promete fazer um basebackup em paralelo e super eficiente,
se chama pgBackRest [1]. Eu particularmente (ainda) não usei, mas ouvi
falar muito bem (de pessoas bem "fodas" no PG, no caso o principal foi o
Stephen Frost, um commiter do PG).

Outra opção que tem, se tiver uma conexão confiável entre esses servidores
(creio que tenha, já que quer fazer replicação), seria usar o pg_basebackup
direto do novo servidor (da AWS) com o parâmetro --xlog-method=stream.
Talvez criar um túnel pra comprimir os pacotes.


> Os passos seriam:
>
>> 1 - Configurar o arquivamento dos wal_files dentro do servidor novo
>> (archive_command no slave)
>>
>
Qual versão você está usando? Apenas a partir da 9.4 é possível fazer
archive de um slave.

Veja o pg_receivexlog também, pode ser mais fácil já deixar coletando.


> 2 - rodar o pg_basebackup no slave
>> 3 - Uma vez que o passo 2 terminar, copiar os arquivos que foram
>> divididos para dentro do servidor novo
>> 4 - juntar os arquivos com o comando JOIN
>>
>
OK.


> 5 - Restaurar a DB (pg_restore)
>>
>
Não é via pg_restore, esse só é usado para backups feitos via pg_dump, você
teria que usar o tar mesmo. Eu nem faria o join num arquivo, dá pra ir
direto:

$ join arquivo1 arquivo2 ... | tar xvfz - -C /path/to/pgdata/



> 6 - Configurar o restore_command para restaurar a DB usando os wal_files
>> que foram configurados ainda no passo 1
>>
>
Lembre-se de já configurar o standby_mode=on, se não vai se tornar primário
ao finalizar de pegar os xlogs.


> 7 - Habilitar a streaming replication.
>
>
OK.

Dá pra juntar o passo 6 e 7 numa configuração só, colocando tanto
restore_command quanto primary_conninfo no recovery.conf, quando ele não
tem mais arquivos pra restaurar via restore_command irá conectar via
primary_conninfo sozinho.

Bem. Está algumas opções pra você, qualquer dúvida avisa aí.

[1] https://github.com/pgbackrest/pgbackrest

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_basebackup - 9.3

[Matheus de Oliveira]

2016-07-05 22:46 GMT-03:00 Patrick B <patrickbake...@gmail.com>:

> o pg_basebackup pode ser usado para gerar uma cópia local da DB?


Sim. O pg_basebackup faz uma cópia física do banco. Para gerar um backup
"standalone" (sem necessidade de usar WALs arquivados), você precisa da
opção --xlog do pg_basebackup (ou `-X fetch`).

Mas cuidado, o backup feito pelo pg_basebackup não possui compatibilidade
entre diferentes plataformas (Windows, Linux, etc.) ou versões do
PostgreSQL. Ou seja, um backup feito no Linux não poderá ser restaurado no
Windows, nem vice-versa (por exemplo).

Explique mais a sua necessidade que podemos dar mais recomendações.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] wal_file missing - PostgreSQL 9.2

[Matheus de Oliveira]

2016-07-03 19:26 GMT-03:00 Patrick B <patrickbake...@gmail.com>:

> 000213B4001A` not found


De onde exatamente vem esse erro? Tem certeza que é um ERROR no log do
PostgreSQL? Pode ser simplesmente que log anterior (...19) seja o último,
daí seu comando no restore_command vai der erro ao requisitar o 1A, isso é
normal.

Sem mais detalhes do processo fica difícil ajudar. De preferência
mostre-nos os logs do PostgreSQL log depois que você o iniciou (como
recovery.conf lá).

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

Re: [pgbr-geral] Data de criação das tabelas

[Matheus de Oliveira]

2016-06-08 11:57 GMT-03:00 Tiago Valério <tiagosvale...@gmail.com>:

> A mesma  pergunta já havia sido feita, Matheus de Oliveira já proveu a
> resposta.
>
> Obrigado


De nada... xD


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

Re: [pgbr-geral] Uso de shared_buffer e aumento de IOPS

[Matheus de Oliveira]

2016-04-25 8:46 GMT-03:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:

> Você configura ele de alguma forma personalizada, ou segue a recomendação
> da documentação mesmo? Que eu vi que ele está configurado para pegar todas
> as transações e manter no máximo 1000.


Depende do ambiente, se fizer snapshot pode manter menos. Comece com 1000 e
veja se atende.


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

Re: [pgbr-geral] contraint already exists (mas não existe!)

[Matheus de Oliveira]

2016-04-25 8:39 GMT-03:00 Alessandro Lima <grandegoia...@gmail.com>:

> Um exemplo de tabela com problema, com o comando "\d banco" apresenta
> banco_pkey como UNIQUE:
> Indexes:
> "banco_pkey" UNIQUE, btree (codigo)
>

Então é isso mesmo, isso é um índice UNIQUE mas não uma PRIMARY KEY.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] contraint already exists (mas não existe!)

[Matheus de Oliveira]

2016-04-23 10:19 GMT-03:00 Alessandro Lima <grandegoia...@gmail.com>:

> Não tenho mais o log do restore, mas percebi que não estava deixando
> incluir e/ou excluir estas constraints devido existir um indíce para a
> chave primária, ao exlcuir o índice foi possível incluir a constraint e
> depois recriar o índice.
>
>
Não entendi ainda, mas pelo que está dizendo me parece que você tinha o
índice mas não a chave primária.

Poderia conectar no psql e executar `\d nome_da_tabela` de uma que está com
problema?


> O problema é que vai ser trabalhoso corrigir isso para centenas de tabelas.
>

Identificando o problema (que ainda não está claro) pode-se fazer consultas
no catálogo para gerar a solução.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Funcão PostgreSQL 9.2

[Matheus de Oliveira]

2016-04-20 19:47 GMT-03:00 drum.lu...@gmail.com <drum.lu...@gmail.com>:

> nao pode ser DEFAULT pois o usuário pode escolher em setar value de sua
> própria escolha
>
>
É exatamente pra isso que o DEFAULT serve, se o inserir um valor
explicitamente vai usar o que inseriu, se não inserir na coluna ou inserir
usando DEFAULT (no INSERT INTO) então vai ser o DEFAULT.


>
>>
>> Me parece uma má ideia, principalmente porque está sujeito à condições de
>> corrida. Por que não usa uma sequence?
>>
>>
>>
>
> é uma possibilidade...
> porém gostaria de ao menos ajuda para comecar com a seq
>

A forma mais simples é usar um campo do tipo `serial` ou `bigserial`. Faça
uns testes e estude um pouco, se tiver dúvidas poste aqui.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Uso de shared_buffer e aumento de IOPS

[Matheus de Oliveira]

2016-04-20 20:16 GMT-03:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:

> Você já utilizou ou utiliza o POWA? Nos servidores de microservices, como
> estão no RDS e já na versão 9.4, estou pensando em usar ele, me parece bem
> completo e tem uma abrangência maior que o pgBadger, por não depender do
> tempo de log, que no nosso caso está em 75ms.


O POWA é bem interessante, e você tem razão. Mas não vai conseguir instalar
a extensão dele no RDS... :(

Creio que a interface do POWA funcione mesmo sem a extensão, não tenho
certeza.

O que eu uso (num ambiente semelhante ao seu, vários micro-serviços no RDS)
é o pgBadger e a extensão pg_stat_statements. Também faço snapshot do
pg_stat_statements para conseguir pegar essa informção de forma temporal (o
PostgreSQL Toolkit tem snapshot deste também).

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Funcão PostgreSQL 9.2

[Matheus de Oliveira]

On Tue, Apr 19, 2016 at 7:31 PM, drum.lu...@gmail.com <drum.lu...@gmail.com>
wrote:

>
>- Se users.code é empty, dá um default value = 1000
>
>
O que significa "empty"? Se for NULL, você pode simplesmente fazer numa
trigger do tipo BEFORE:

IF (NEW.code IS NULL) THEN
NEW.code = 1000;
END IF;

Mas, provavelmente você quer simplesmente setar um DEFAULT:

ALTER TABLE users ALTER code SET DEFAULT 1000;


>-
>- e increment_client_code em companies deve auto-incrementar pelo
>próximo client code
>
> O que fiz até agora:
>
> DROP FUNCTION IF EXISTS client_code_increment_count();
>> CREATE OR REPLACE FUNCTION "public"."client_code_increment_count" ()
>> RETURNS TABLE("code" INT) AS
>> $BODY$
>> SELECT MAX(CAST(users.code AS INT)) FROM users WHERE users.code ~ '^\d+$'
>> AND company_id = 2
>>
>
Me parece uma má ideia, principalmente porque está sujeito à condições de
corrida. Por que não usa uma sequence?

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

Re: [pgbr-geral] Uso de shared_buffer e aumento de IOPS

[Matheus de Oliveira]

2016-04-20 8:51 GMT-03:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:

> Isso vai ser muito util mesmo...
>>
>
> O que você usa para monitorar degradação nos planos de execução?
> auto_explain?
>

Geralmente faço a análise pelo tempo das consultas, usando tanto
log/pgBadger quanto pg_stat_statements (não só tempo mas outros fatores
como número de linhas retornados e arquivos temporários gerados). O
auto_explain também é útil, mas costumo depender deste cara mais após já
identificar problema (daí posso analisar como era antes e como é agora), ou
simplesmente ter o plano mais rapidamente.

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

Re: [pgbr-geral] Uso de shared_buffer e aumento de IOPS

[Matheus de Oliveira]

2016-04-19 8:13 GMT-03:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:

> Problema que não temos esse histórico.
>
>
Não precisa, a ideia é habilitar agora e observar.

O postgresql-toolkit tem um esquema de snapshot que pode te ajudar [1]
(nunca usei, eu costumo fazer o mesmo na mão).



> Mas pelo que pude notar é que a uns 2, 3 meses a atrás o uso de IOPS era
> quase 10x menor, e o sistema não cresceu nessa proporção, nem de tamanho e
> nem de acessos.
>
>
Como está medindo isso?


> Não sei alguma degradação de estatísticas? autovacuum ta ON, não seria o
> bastante? Ou teria mais alguma manutenção que teria que ser feita
> periodicamente? vacuum analyze?
>

Depende, pode ser planos de execuções piores. As análises que passei podem
ajudar a identificar alguns pontos (tudo bem que foquei mais checkpoints).
Tem noção da taxa de escrita vs leitura desse sistema?

[1] http://postgres-toolkit.readthedocs.org/en/latest/pgperf_tables.html

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

Re: [pgbr-geral] Alterar tablespace

[Matheus de Oliveira]

2016-04-18 14:55 GMT-03:00 Danilo Silva <danilo.dsg.go...@gmail.com>:

> Preciso mover toda a base para uma outra partição, qual seria a melhor
> solução, criar uma outra tablespace e executar um alter database alter
> tablespace?


Não vejo uma necessidade de tablespace necessariamente, você poderia
simplesmente mover o diretório PGDATA para o novo local.

A forma de fazer isso varia dependendo do seu SO/Distro e forma como
instalou o PostgreSQL.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PGSQL_TMP

[Matheus de Oliveira]

2016-04-14 19:19 GMT-03:00 Raphael Coutinho <rcoutosi...@gmail.com>:

> Estou querendo separar o pgsql_tmp do disco SSD e colocar no SAS. Já que o
> forte do SSD é leitura, acredito que separar esse diretório vai me trazer
> um ganho de performance, conservar a vida útil do SSD.


Nem pense em montar uma partição no pgsql_tmp direto, nem fazer link
simbólico nem nada do tipo. Lembre-se que no layout físico do PostgreSQL
apenas o diretório pg_xlog aceita uma intervenção manual para ser um link
simbólico, os demais arquivos/diretórios não devem se "mexidos" manualmente
(salvo talvez a troca dos links simbólicos no pg_tblspc, em versões
recentes e com muito cuidado).

Se quiser separar arquivos temporários, crie um tablespace no outro disco e
configure o parâmetro temp_tablespaces.

O Dutra fez um bom comentário quanto à efetividade dessa operação (que
compartilho), quis comentar somente sobre como fazer (pois vejo muita gente
fazendo errado).

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] converter enconding

[Matheus de Oliveira]

2016-04-15 22:23 GMT-03:00 Douglas Fabiano Specht <douglasfabi...@gmail.com>
:

> estou recebendo a string com enconding acho que LATIN1, mas nao consigo
> fazer o decode para utf8, alguma sugestão.
>
> select convert(' número 77668 já está ', 'LATIN1', 'UTF8')
>


Não entendi, se está tentando corrigir o encoding desse texto, e sua
base/conexão é UTF8, então o texto foi lido de UTF8 em latin1, agora
apresentado como UTF8, daí teria que recuperar seu bytea como latin1 e
depois trazer pra text como se estivesse em UTF8 (veja que bytea não está
em nenhum encoding, são só bytes):

postgres=# SELECT convert_from(convert_to(' número 77668 já está ',
'LATIN1'), 'UTF8');
  convert_from

  número 77668 já está
(1 row)

É isso que queria?

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Uso de shared_buffer e aumento de IOPS

[Matheus de Oliveira]

2016-04-17 15:58 GMT-03:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:

> Boa tarde.
>
> Tenho um ambiente de produção, que o ratio de uso de shared_buffer está em
> 0,94, e normalmente beirava os 0,99. Existe algum fator que possa estar
> causando essa baixa? E notei inclusive um aumento nos IOPS dos discos.
>
>
Não pode ser simplesmente um crescimento natural da sua aplicação?

O recomendado é você analisar o que está acontecendo. Um bom começo seria:
- Pode ter aumentado a escrita na base?
- Verifique se checkpoints não estão ocorrendo com frequência maior do que
esperado (snapshots da pg_stat_bgwriter pode ajudar, ou log_checkpoints)
- Verifique se os backends não estão tendo que escrever buffers devido à
shared_buffers estar muito poluída (pg_stat_bgwriter também)
- Verifique a criação de arquivos temporários (pg_stat_* ou log_temp_files)
- Verifique no tempo quando a taxa de uso do cache diminui (pg_buffercache
e snapshot da pg_stat_database ajudam nessa tarefa)


>
> PostgreSQL 9.2.13
>

Atualize pra ontem, a versão 9.2 já está em 9.2.16!


>
>
> maintenance_work_mem = 3000MB
> wal_buffers = 16MB
>
> work_mem = 40MB
>

Pode estar muito baixo (ou não, depende), analise o uso de arquivos
temporários.


> ...
> max_prepared_transactions = 50
>

Está mesmo usando prepared transactions?


> ...
> checkpoint_segments = 200
>
checkpoint_completion_target = 0.9
>
checkpoint_timeout = 30min
>

Dependendo do caso 30min pode ser muito, porque com CCT=0.9 a escrita dos
buffers sujos vai ser bem suave, com isso existe a chance de não dar tempo
de limpar os buffers sujos da shared_buffers, forçando os backends a
escreverem esses buffers, pra confirmar se isso acontece ou não você pode
analisar se há crescimento considerável do valor da buffers_backend na
pg_stat_bgwriter.

Nesse caso aumentar a shared_buffers também poderia ajudar, mas teria que
ter mais cautela, analise primeiro e retorne com os valores.

...
>
bgwriter_lru_maxpages = 500
> bgwriter_lru_multiplier = 3
> bgwriter_delay = 50ms
>
>
Verifique se o bgwriter não está escrevendo demais e "atrapalhando" ao
invés de ajudar.

Veja que tudo que citei (exceto atualização da versão) são somente
"cheiros" ou "dicas" para verificar se está tudo bem e o que pode melhorar.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Pg_dump de 8.0.3 para 9.4.4

[Matheus de Oliveira]

2016-03-17 10:41 GMT-03:00 André Ormenese <aormen...@gmail.com>:

> Tenho uma base ainda na versão 8.0.3 (eu sei que é loucura, mas essas
> coisas acontecem)
>
[...]
> pg_dump: [archiver (db)] query failed: ERROR:  transaction is read-only
> pg_dump: [archiver (db)] query was: COPY public.tb_cbo (cod_cbo, dsc_cbo)
> TO stdout;
>

Além de você estar numa versão já mumificada, ainda está numa release
antiga dela. Você está na 8.0.3 e a série 8.0 chegou até 8.0.26, você está
23 releases atrás... E, sem surpresas alguma, você está de frente à um bug
conhecido da 8.0.3.

Na versão 8.0.4 (1 release à frente da sua) esse bug foi corrigido [1][2]:

- Fix the sense of the test for read-only transaction in COPY

  The code formerly prohibited COPY TO, where it should prohibit COPY
FROM.

[1] http://www.postgresql.org/docs/8.0/static/release-8-0-4.html
[2] http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3dfec7f

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Erro Restaurar Backup

[Matheus de Oliveira]

Em 13 de mar de 2016 12:58, "Edson - Amplosoft Software" <
ed...@openmailbox.org> escreveu:
>
> Qual e o grupo do telegrama?

https://listas.postgresql.org.br/pipermail/pgbr-geral/2015-December/041959.html

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

Re: [pgbr-geral] Desempenho de índices

[Matheus de Oliveira]

2016-03-11 16:31 GMT-03:00 Danilo Silva <danilo.dsg.go...@gmail.com>:

> Existe diferença entre criar índices assim:
> CREATE INDEX foo_c1_idx ON foo (campo1);
> CREATE INDEX foo_c2_idx ON foo (campo2);
>
> ou assim:
> CREATE INDEX foo_idx ON foo (campo1,campo2);
>

Tem sim, o artigo do Vinícius explica bem, mas vou resumir nos termos da
questão e com exemplo:

1. O índice `foo_c1_idx` poderia ser usado de forma ótima para consultas
`WHERE campo1  = $1` mas não para `WHERE campo2 = $1`
2. O índice `foo_c2_idx` é o oposto, ótimo para `WHERE campo2 = $1` mas não
para `WHERE campo1 = $1`
3. Se você tiver somente `foo_c1_idx` e `foo_c2_idx' e a consulta `WHERE
campo1 = $1 AND campo2 = $2`, o PostgreSQL pode escolher por usar apenas um
dos índices (daí considera somente campo1 ou campo2 e filtra o outro campo
na tabela), o que pode ser suficientemente bom caso seja bem seletivo.
4. Ainda é possível usar ambos para `WHERE campo1 = $1 AND campo2 = $2` com
BitmapAnd (veja [1] depois), mas não é tão eficiente quanto se tivesse o
`foo_idx`, ou seja, para `WHERE campo1 = $1 AND campo2 = $2`, o `foo_idx` é
certamente o ideal (também é ideal para outros casos, como `WHERE campo1 =
$1 ORDER BY campo2` ou `GROUP BY campo1, campo2`, etc.).
5. Supomos que você tenha apenas o `foo_idx`, como o índice inicia com
`campo1`, é possível usá-lo de forma ótima para `WHERE campo1 = $1` mas não
para `WHERE campo2 = $1`. Ter `foo_idx` e `foo_c1_idx` é geralmente
redundante (exceção seria se `foo_idx` fosse *muito* maior que
`foo_c1_idx`), então é comum ter `foo_c2_idx` e `foo_idx`, mas *NÃO* ter
`foo_c1_idx` (pois seu uso ideal já é contemplado pelo `foo_idx`).

Sobre o uso de índices compostos o artigo do Vinícius é bem legal, eu
queria só complementar com um meu que também comenta sobre o uso de
múltiplos índices, que citei em (4), leia em [1].

[1]
http://dextra.com.br/como-o-postgresql-usa-multiplos-indices-na-mesma-consulta/

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Erro Restaurar Backup

[Matheus de Oliveira]

2016-03-12 23:24 GMT-03:00 Pablo Farias <pabloapfar...@gmail.com>:

> gerei um backup com o pgAdmin um arquivo com extensão .backup.
> O servidor esta instalado o postgresql 9.5.1
> Acontece que agora de forma alguma consigo restaurar o backup.
>
> O conteudo do erro esta no link
>
> pastebin.com/X3CqZY1w
>

Só para adiantar, já resolvemos esse problema via grupo do Telegram. O erro
era que o dump foi gerado com --data-only, logo não tem o esquema das
tabelas para restaurar.

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

Re: [pgbr-geral] listar associação dos databases com a pasta base

[Matheus de Oliveira]

2016-03-04 14:57 GMT-03:00 Luiz Henrique <luiz.henriqu...@gmail.com>:

> 1.Cada pasta indica um database ?
>

Sim.


> 2.Como relacionar/identificar cada pasta com seu respectivo database ?
>

Esse número indica o `pg_database.oid`, por exemplo, para encontrar qual
base se referencia o diretório `6681487`:

SELECT datname FROM pg_database WHERE oid = 6681487;

Lembre-se também que alguns bancos de dados podem estar em tablespaces, se
estiver investigando o layout lembre-se de analisar os tablespaces (links
simbólicos no diretório pg_tblspc).

Ah, pergunta: por que se importa com isso? (apenas para conhecimento/estudo
é um resposta perfeitamente aceitável, ;)

Dependendo do que queira fazer (espaço em disco por exemplo), existem
maneiras de se analisar via SQL.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dump muito grande

[Matheus de Oliveira]

2016-02-27 11:32 GMT-03:00 Antonio Cesar <cgcesarsoa...@gmail.com>:

> Estou com arquivo dump com 2.118.212 kb e ao fazer o backup zip o arquivo
> so que quando vou desconpactar retorna o seguinte erro: falha no CRC


Não ficou muito claro. Este erro está ao tentar descompactar um arquivo
.zip?

Se for, não tem nada a ver com o PostgreSQL, aparentemente o arquivo .zip
está corrompido.

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

Re: [pgbr-geral] RESULT TABLE DINAMICAMENTE

[Matheus de Oliveira]

2016-02-25 16:33 GMT-03:00 lu moraes santos <djrlumor...@gmail.com>:

> entao o PG nao aceita vc mudar a estrutura no select de retorno que seja
> diferente da estrutura declarada na PL.


Não aceita. E?

Minha dica é usar NULL nas colunas que não te interessam para cada caso.

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

Re: [pgbr-geral] RESULT TABLE DINAMICAMENTE

[Matheus de Oliveira]

2016-02-24 15:33 GMT-03:00 lu moraes santos <djrlumor...@gmail.com>:

> pelo que estou vendo no seu codigo, voce preenche os campos que nao serao
> retornados com null para atender a estrutura que foi definida no return
> table???
>
>
Correto.

Se sim como ficaria no caso de fazer um agrupamento??/
>

Da mesma forma, não entendi a dúvida.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] replicação bidirecional

[Matheus de Oliveira]

2016-02-23 22:03 GMT-03:00 Fernanda Forbici <fernandaforb...@gmail.com>:

> Qual ferramenta, gratuita, vocês recomendam para replicação bidirecional?


Quanto às ferramentas o Euler já recomendou as disponíveis (e as que eu
diria também). Mas sinto-me na obrigação de perguntar:

Por que razão você precisa ou acha que precisa de replciação bidirecional?

Pergunto porque é comum as pessoas quererem usar esse tipo de replicação de
forma inadvertida e desnecessária (sem entender bem os problemas inerentes
da replicação bidirecional assíncrona, como conflitos nas operações).

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RESULT TABLE DINAMICAMENTE

[Matheus de Oliveira]

2016-02-22 7:17 GMT-03:00 lu moraes santos <djrlumor...@gmail.com>:

> Então eu não queria especificar quais campos no return. Pq vou criar uma
> função que vai receber um parametro Resumido ou Detalhado. Se Resumido vai
> retornar tais campos, se detalhado retorna tais campos, por isto que falei
> de retornar os campos dinamicamente. Grato


Seria o seguinte?

IF (p_resumido) THEN
RETURN QUERY SELECT foo, bar, null, null FROM ...
ELSE
RETURN QUERY SELECT foo, bar, baz, zaz FROM ...
END IF;

Se quiser mais dinâmico:

v_query := $$SELECT foo, bar, baz, zaz FROM ... $$;
IF (p_resumido) THEN
RETURN QUERY EXECUTE 'SELECT foo, bar, null, null FROM
('||v_query||') t';
ELSE
RETURN QUERY EXECUTE v_query;
END IF;

Era isso que queria?

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RESULT TABLE DINAMICAMENTE

[Matheus de Oliveira]

2016-02-19 17:10 GMT-02:00 lu moraes santos <djrlumor...@gmail.com>:

> return query
> SELECT * from tmplucratividade;
>
> Neste ex. a tabela  tmplucratividade tem exatamente a mesma estrutura da
> TABLE.
>
> Porem queria saber se existe uma maneira de eu retornar uma QUERY
> DINAMICAMENTE
>
> exemplo:
>
> RETURN QUERY Select Nome, Endereco From CLIENTE Order by Nome;
>

Não sei se entendi, o que é "dinâmico" nessa query? Quer retornar apenas
algumas colunas? Se quiser, basta definir somente estas no RETURNS TABLE.

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

Re: [pgbr-geral] Problema com campo numeric

[Matheus de Oliveira]

Por favor, evite o top-posting, responda abaixo da mensagem, como farei...

2016-01-05 14:08 GMT-02:00 Jean - GECONTROL <j...@gecontrolsistemas.com.br>:

> Eu editei no grid. Mas é estranho o comportamento, tanto na aplicação como
> no grid. Não testei executando uma instrução SQL.


Sinceramente não me parece um problema do lado do PostgreSQL, mas sim da
aplicação.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problema com campo numeric

[Matheus de Oliveira]

2015-12-23 17:12 GMT-02:00 Emerson da Silva Chalegre <emerchale...@gmail.com
>:

> Em funcões e triggers de vez em quando tenho problema parecido, e com isso
> pego o valor e multiplico 1..
> Tente assim, pode ser que resolva.
> (0.2523*1.)
>

Isso não era pra acontecer se você estiver usando apenas tipo NUMERIC, tem
certeza que não tem nenhum double precision ou real (a.k.a. float8 e
float4) envolvidos nessas operações? (a mesma pergunta vale para o OP).

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] connect: Bad file descriptor

[Matheus de Oliveira]

2015-12-23 22:32 GMT-02:00 Ronaldo Bernardes Pereira <
ronaldobernar...@gmail.com>:

> Essa função é criada quando o invasor tem acesso ao usuário postgres. A
> partir dai, o invasor pode usar o comando copy para ler arquivos do Linux
> para o banco de dados, criar funções que criam arquivos e por ai vai.


Um excelente motivo para não usar o usuário "postgres" do banco em
aplicações, como vemos muita gente fazendo por aí... Eu nem libero o
usuário "postgres" no pg_hba.conf para conexão remoto, somente via "peer".

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

Re: [pgbr-geral] TO_CHAR EM CAMPO BIGINT

[Matheus de Oliveira]

2015-12-16 16:43 GMT-02:00 Eduardo Az - EMBRASIS <eduard...@embrasis.com.br>
:

> Estou criando uma view , aonde um campo de cpf quero que já saia formatado.
>
> Porém, ao criar, colocando o to_char, apresenta um erro:
> 
> SELECT to_char(cpf,'000"."000"."000-00') AS cpf  FROM clientes ...
>
> ERRO:
> ERROR:  cannot change data type of view column "cpf" from bigint to text
>

Pelo erro você não está tentando criar a view, mas sim alterá-la. Para
alterar uma view não é possível alterar o tipo dos dados, nesse caso você
tem que excluí-la e criá-la novamente.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Coluna data - Migration

[Matheus de Oliveira]

2015-12-15 2:10 GMT-02:00 drum.lu...@gmail.com <drum.lu...@gmail.com>:

> A "status label id 580105" tem 80900 Jobs deletados. Preciso migrar tudo
> para a "status label id = 577418" para depois (TALVEZ) deletar a  580105
>
> Porem, estou com dificuldades para criar o script.
> Poderiam me dar uma luz por favor?
>

Por favor, tente ser mais claro quanto ao seu modelo e seus objetivos.

Me parece que quer simplesmente:

UPDATE jobs SET status_label_id = 577418
WHERE status_label_id = 580105 AND deleted;

Mas não ficou nem um pouco claro sua dúvida.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Linhas analisadas nas estatísticas

[Matheus de Oliveira]

2015-12-11 17:08 GMT-02:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:

>
> INFO:  "xxx": scanned 104314 of 104314 pages, containing 715972 live rows
> and 2718 dead rows; 30 rows in sample, 715972 estimated total rows
>
> Isso quer dizer que ele calculou a estatística em cima de 300mil linhas?
>
> default_statistics_target = 1000# range 1-1
>

Dei uma olhada bem por cima no código em [1] (veja também a linha 1197,
onde emite a mensagem), e pelo que entendi o número de linhas que são
consideradas para a amostragem é o "statistics_target" multiplicado por um
fator fixo de 300 (não parei pra analisar o código melhor e ver se varia em
algumas situações, mas em alguns testes que fiz sempre deu exatamente 300).
A ideia é analisar uma amostragem de tuplas na tabela, essa amostragem será
de *pelo menos* 300*statistics_target caso a tabela tenha mais tuplas que
isso, mas pode ser mais; entretanto, serão armazenados nos
histogramas/valores comuns/etc. apenas statistics_target.

[1]
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/analyze.c;h=ddb68abf6b4e358a5b69913ba66de65fdf367860;hb=HEAD#l1762

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Out of Memory com PG_DUMP

[Matheus de Oliveira]

2015-12-07 10:45 GMT-02:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:

> Problema é que de um tempo para cá ao fazer o dump está ocorrendo estouro
> de memoria dessa maquina cliente.
>
> pg_dump: reading rewrite rules
> pg_dump: reading large objects
> pg_dump: reading dependency data
> pg_dump: saving encoding = UTF8
> pg_dump: saving standard_conforming_strings = on
> pg_dump: saving database definition
> Killed
>
> A máquina tem 7,5GB de RAM, com 5GB livres, mesmo assim estoura.
>
> A base tem 21GB, e possui basicamente largeobjects(é uma aplicação legado
> que ainda utiliza).
>

Está usando largeobjects propriamente dito (via pg_largeobjects) ou campos
bytea?

O dump realmente tem um consumo excessivo de memória para backup de bytea,
principalmente caso tenhas uma linha com bytea's muito grandes.

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

Re: [pgbr-geral] Out of Memory com PG_DUMP

[Matheus de Oliveira]

2015-12-11 16:08 GMT-02:00 Matheus de Oliveira <matioli.math...@gmail.com>:

>
> Está usando largeobjects propriamente dito (via pg_largeobjects) ou campos
> bytea?
>
> O dump realmente tem um consumo excessivo de memória para backup de bytea,
> principalmente caso tenhas uma linha com bytea's muito grandes.
>

Ah. Mais uma pergunta importante. Está usando um formato binário? Se não,
pode tentar com o binário (-Fc ou -Fd) e ver se resolve?

Quanto ao tamanho das linhas, você pode ter uma ideia da que ocupa mais
espaço da seguinte forma:

SELECT max(length(coluna_bytea)) FROM tabela;

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

Re: [pgbr-geral] Ajuda para montar ambiente com servidores multi-master

[Matheus de Oliveira]

2015-12-03 12:06 GMT-02:00 Mauricio Tavares <mfx1...@gmail.com>:

> Em um primeiro teste, tentei usar Postgres-XC, no entanto, a replicação
> de dados somente funcionou quando foram feitas exclusivamente no NÓ DO
> COORDENADOR. Explicando: se eu fizer uma transação de dados diretamente em um
> dos nós, tal operação não é replicada para os outros nós.


Sim. É assim que o XC trabalha (e também o XL). Nunca se deve escrever
direto nos nós de dados, sempre nos coordenadores, pois estes serão
responsáveis por escrever nos nós de dados. Mas veja, você pode ter quantos
coordenadores quiser, e quanto nós de dados quiser.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Recuperação Base Postgres 9.0

[Matheus de Oliveira]

2015-12-07 18:10 GMT-02:00 Bruno Felipe <bruno.dc.fel...@gmail.com>:

> estou tentando recuperar uma base de dados da versão 9.0 do postgres, ele
> estava instalando em um HD com windows 7, porém o sistema operacional deu
> problema e não liga mais, consegui recupera a pasta de instalação completa
> do postgres.
> Preciso recuperar os dados que contém lá, alguém sabe como eu posso fazer?
>

Você precisa de um computador com o mesmo sistema operacional e arquitetura
(32bits/64bits):

1. Instale a mesma versão maior do PostgreSQL (no caso instale a 9.0.23,
mesmo que o último número fosse menor)
2. Após a instalação vá no gerenciador de serviços e pare o serviço do
PostgreSQL
3. Em seguida, copie o diretório "data" para o local da instalação (se não
me engano %PROGRAMFILES%/PostgreSQL/9.0/data), substituindo o da instalação
atual
4. Inicie o serviço novamente
5. Conecte e verifique se está tudo OK. Se falhar, nos avise por aqui
passando os detalhes do que falhou (qualquer erro, log, etc.)
6. A versão 9.0 já foi descontinuada [1], atualize imediatamente para uma
versão mais recente

[1] http://www.postgresql.org/support/versioning

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off-topic] Only NoSQL

[Matheus de Oliveira]

Este tópico já teve bastante informação, eu queria só levantar alguns
pontos que acho relevante.

2015-11-05 16:48 GMT-02:00 Matheus Saraiva <matheus.sara...@gmail.com>:

> Ok, muito se fala em usar NoSQL para casos específicos, geralmente
> resultando uma solução final mista entre NoSQL e Relacional.
>

Isso é mesmo muito comum, por exemplo, alguns exemplo:

- é comum usar bancos de dados chave/valor, como o Redis, Aerospike, e até
memcached como um cache distribuído ou até mesmo armazenar dados de sessão
de usuário, carrinho de compra, etc.
- usar ElasticSearch, Sphinx, Solr, etc. para prover uma busca mais
avançada, mas sempre armazena-se os dados em outros lugares para poder
reconstruir os índices nesses bancos.
- entre outros mais avançados, BigData-like, como Hadoop (HDFS, HBase,
etc.) ou Spark, para processamento de grandes volumes de dados


> Mas o que dizer de uma solução puramente NoSQL, ou seja, ter o mongoDb
> como único SGDB de uma aplicação?
> Isso é praticável? Que problemas e vantagens eu teria em fazer tal coisa?
>

Sinceramente só vejo desvantagens nesse caminho, não vou fazer uma lista
enorme pois muita gente já fez... :)

O que vejo é muita gente usando um NoSQL por não conhecer a real capacidade
e extensibilidade do PostgreSQL. Tanto que fiz uma palestra sobre o assunto
onde expresso mais detalhadamente minha opinião no assunto: "PostgreSQL,
porque você não precisa de NoSQL" [1][2] (OBS: não sou *contra* NoSQL, só
acho que tem que conhecer bem antes de usar, qual usar, e saber as
limitações e as vantagens).

[1]
http://www.slideshare.net/matheus_de_oliveira/postgresql-porque-voc-no-precisa-de-nosql
(somente slides)
[2]
http://www.infoq.com/br/presentations/postgresql-e-porque-voce-nao-precisa-de-nosql
(vídeo)

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consultar valores através da tabela de sistema.

[Matheus de Oliveira]

2015-10-27 10:44 GMT-02:00 Junior Miranda <flmirandajun...@gmail.com>:

> Obrigado Rafael. Mas são muitas tabelas. Sem falar que o banco não para de
> crescer...


Na boa. Se você quer fazer isso dinamicamente é algo a ser usado na
aplicação de forma contínua (não uma análise exploratória, somente uma vez
ou outra), então eu recomendo repensar um pouco no seu esquema.

Talvez usar triggers e algum modelo de auditoria que salvem esses dados em
uma única tabela.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] replicação seletiva de database produção para homologação

[Matheus de Oliveira]

2015-10-27 14:16 GMT-02:00 Luiz Henrique <luiz.henriqu...@gmail.com>:

> Atualmente é o que eu estou fazendo, dump...restore. O Problema é o tempo,
> 2h para o dump e 6h para restore. Por isso estou procurando outras
> alternativas...


Sinceramente me parece que dump+restore vai ser mais simples mesmo. Quanto
ao dump você já precisa ter backups lógicos mesmo, então seria necessário
executar sempre, certo?

Já quanto ao restore, como está chamando? Está usando opção de paralelismo?

Eu particularmente acho muito válido usar dump+restore (quando possível)
para sincronização de ambientes dev/homolog, assim, na mesma tacada, você
confirma que seus backups lógicos estão consistentes.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida com SQL

[Matheus de Oliveira]

2015-10-22 14:45 GMT-02:00 Rubens José Rodrigues <
rubens.rodrig...@batistarepresentacoes.com>:

> Por favor, ajude-me dizendo como eu poderia "marcar" o elemento agrupado
> (campanha, codcet, numcondicao) de maior valor.
>
> Observe abaixo que criei uma coluna "Atendido" para ilustrar como seria o
> resultado esperado, ela não existe na entidade, mas se for necessário posso
> cria-la (pois é uma tabela temporária).
>
> CAMPANHACODCET  NUMCONDICAO CODCATITE   VALOR
> ATENDIDO
> Caldo 168g  2163250 1   122490925971.00
> SIM
> Caldo 168g  2163250 1   122490912512.33
> NAO
> Caldo 168g  3531694 1   1224909255269.56
> SIM
> Caldo 168g  3531694 1   1224909114596.32
> NÃO
>

Você quer que o de maior valor tenha ATENDIDO = 'S', certo?

Nesse caso você pode usar window function com subconsulta:

SELECT
t.campanha, t.codcet, t.numcondicao, t.codcatite, t.valor,
CASE
WHEN (row_number() OVER(PARTITION BY t.campanha, t.codcet,
t.numcondicao ORDER BY t.valor DESC)) = 1 THEN 'SIM'
ELSE 'NAO'
END AS atendido
FROM sua_tabela t;

Se quiser conhecer mais sobre window functions, eu escrevi um artigo sobre
isso há um tempo atrás [1][2], espero que esteja claro.

No exemplo acima eu usei a função ROW_NUMBER para enumerar as linhas de
forma decrescente, ou seja, o de maior valor recebe 1, o segundo maior 2, e
assim por diante. Daí peguei o que era igual a 1, garantidamente o de maior
valor.

Um problema desse método é que se tiver dois itens empatados com o maior
valor, apenas um será marcado de forma aleatória. Caso queira marcar ambos,
basta simplesmente usar a função RANK ao invés da ROW_NUMBER.

[1] http://dextra.com.br/window-functions-no-postgresql-parte1/
[2] http://dextra.com.br/window-functions-no-postgresql-parte-2/

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ULTIMO REGISTRO ADICIONADO

[Matheus de Oliveira]

2015-10-21 12:03 GMT-02:00 Eduardo Az - EMBRASIS <eduard...@embrasis.com.br>
:

> -como ID é serial, via select vejo o ultimo registo com o max()


Ok. Muita resposta, posso resumir? Existem, que eu saiba, ao menos 3 opções
confiáveis para isso (duas foram comentadas). Vou mostrar um pseudo-código
baseado em PL/pgSQL...

Solução 1: antes de inserir na tabela de pedidos você chama manualmente a
função nextval e salva o valor gerado:

SELECT nextval(pg_get_serial_sequence('pedidos', 'id')) INTO v_id;
-- use o valor salvo na variável para inserir na pedidos:
INSERT INTO pedidos(id, funcionario, ...) VALUES(v_id, p_funcionario,
...);
-- Na hora de inserir na pedido_itens (para cada item):
INSERT INTO pedido_itens(id_pedido, id_produto, ...) VALUES(v_id,
p_produto, ...);


Solução 2: após inserir em pedidos, use a função currval para recuperar o
valor:

-- Inserir na pedidos normalmente (veja que não referencio o "id", mas
também poderia usar o DEFAULT):
INSERT INTO pedidos(funcionario, ...) VALUES(p_funcionario, ...);
-- Busca o valor gerado usando a função currval
SELECT currval(pg_get_serial_sequence('pedidos', 'id')) INTO v_id;
-- Aqui é igual à anterior:
INSERT INTO pedido_itens(id_pedido, id_produto, ...) VALUES(v_id,
p_produto, ...);

Solução 3: use a cláusula RETURNING do comando INSERT:

-- Inserir na pedidos e já recupera o valor gerado, numa só tacada:
INSERT INTO pedidos(funcionario, ...) VALUES(p_funcionario, ...)
RETURNING id INTO v_id;
-- Aqui é igual à anteriores:
INSERT INTO pedido_itens(id_pedido, id_produto, ...) VALUES(v_id,
p_produto, ...);

Na minha opinião, a solução 3 é sem dúvida a melhor. Por vários motivos:

1. Não precisa duas idas ao servidor, em uma tacada só já faz o INSERT e
recupera o valor gerado;
2. Evita qualquer erro que possa acontecer caso seja gerado um novo id pela
sequence na mesma sessão (só seria possível vai trigger, nesse caso, mas já
vi acontecer);
3. Não precisa se preocupar com o nome da sequence, na verdade nem precisa
se preocupar com sua existência;
4. Funciona mesmo que troque o modelo para gerar "id" (comum acontecer
quando tem-se mais de um servidor de banco);
... deve ter mais ...

OBS: A função pg_get_serial_sequence recupera o nome da sequence que foi
criada usando o tipo serial ou OWNED BY. Acho mais simples e confiável que
usar o nome da sequence. Tudo bem que a solução 3, minha preferida, nem
precisamos de nos preocupar com a sequence.

OBS2: Esse erro é bem comum, infelizmente. Aliás tem vários erros comuns
que são bem simples, veja [1] (nem é merchan... :P )

[1]
http://www.slideshare.net/matheus_de_oliveira/dev-camp2015-top5falsassuposicoesprogramadores
(slide 58 fala sobre esse caso, não é específico de PostgreSQL)

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PGBR2015 - Prêmio Destaques Comunidade

[Matheus de Oliveira]

Meus votos...

2015-10-09 13:26 GMT-03:00 Flavio Henrique Araque Gurgel <fha...@gmail.com>:

>   * Contribuição com código no PostgreSQL;
>

Fabrízio e Euler. Nem preciso comentar o porquê, certo?

  * Contribuição com código em ferramentas livres relacionadas ao
> PostgreSQL:
>

Guedes e Fike pelos trabalhos no pgvm


>   * Pessoa que melhor contribuiu na lista pgbr-geral;
>

Gurgel e Euler.


>   * Melhor contribuição na organização da comunidade brasileira;
>

Fike (por todo trampo na infra) e Fabrízio (por estar incentivando tanto a
comunidade e pelo PGBR).


>   * Melhor artigo técnico publicado nos últimos 2 anos.
>

Telles e Fabrízio.


É isso... ;)

Infelizmente não poderei participar do PGBR esse ano, minha vida está um
pouco conturbada. Mesmo assim agradeço imensamente à todos que votaram em
mim... Valeu cambada... :)

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Questionamentos sobre performance.

[Matheus de Oliveira]

2015-10-07 16:37 GMT-03:00 Emerson Martins <emersonmarti...@gmail.com>:

> Estou a participar de uma migração de Bancos  Firebird (5 bds separados
> Fisicamente) para um PostgreSQL único rodando em um servidor *IBM System
> X3650 M4 **Processador XEON E5-2600, 8 GB de RAM e 2 discos SAS 300 GB
> 10k RMP em RAID 0)*.
>
>
RAID 0? Sério?

Vai ter replicação? Se sim, pretende usar o secundário para consultas?

Qual o sistema operacional e distribuição? Fique de olho na versão do
kernel [1].

Não chequei, mas se esse servidor tiver HT, faça testes com este habilitado
e desabilitado.


> A quantidade de usuários simultâneos em média simultaneamente seria *em
> média 100 usuários. *
>
>
Eita frase doida... Mas está "entendível", acontece... xP

Enfim, você sem dúvida vai precisar de um pool de conexões. Se sua
aplicação não tem um próprio (ou for app desktop), recomendo fortemente o
pgbouncer [2].


> Então queria ajuda dos colegas para fazer um teste de performance antes de
> colocar em produção se o servidor  responderia bem no quesito desempenho.
> Quando falo ajuda, se existe algum tool que possa simular esses testes
>

Além do pgbench, já indicado, você pode também usar o pgbench-tools [3]. O
legal dessa ferramenta, é que monta uma bateria de testes completa (usando
o pgbench) e traz resultados em gráficos e HTML.

Mesmo usando o pgbench, seria interessante você tentar fazer um teste de
carga usando a sua aplicação real ou ao menos tentar montar um teste com o
pgbench em cima de consultas que ela utilizará sob uma base da própria
aplicação (se possível com dados reais, como está numa migração, talvez
seja fácil obter).

[1] http://www.databasesoup.com/2014/11/good-kernel-bad-kernel.html &
http://www.databasesoup.com/2014/09/why-you-need-to-avoid-linux-kernel-32.html
[2] https://github.com/gregs1104/pgbench-tools
[3] https://pgbouncer.github.io/

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] testar latencia AWS

[Matheus de Oliveira]

2015-09-24 8:21 GMT-03:00 Douglas Fabiano Specht <douglasfabi...@gmail.com>:

> Atualmente nosso banco está no datacenter da UOLDIVEO e temos uma latência
> media de 40s e os clientes reclamam as vezes da lentidão.


Tem certeza que usou a unidade correta? Não quis dizer 40ms?

40s de latência é insano...

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Streaming Replicação

[Matheus de Oliveira]

2015-09-15 12:23 GMT-03:00 Raphael Coutinho <raphael.couti...@dbmax.com.br>:

> Sim, ele está configurado no conf dos nossos Servers Standby, O
> Standby que fica na rede local, fica a  maior parte do tempo em Streaming,
> porém o que fica remoto (AWS), recebe os archives zipados via scp, aplica e
> o archive_cleanup se encarrega da limpeza. O intuito do Shell é tratar da
> limpeza dos archives gerados e armazenados aqui no ambiente do MASTER, a
> ideia é ele pegar o último segmento aplicado no Standby01 e no Standby 02,
> pegar o menor dentre eles, e limpar tudo para trás.
>

Não seria bem mais simples então você buscar o primeiro arquivo presente em
ambos servidores remotos e apagar a partir desses (assumindo que usas
archive_cleanup em cada secundário)?

Algo mais ou menos assim:

first_not_needed_1=$(ssh remoto1 "ls /path/to/archive | head -n1")
first_not_needed_2=$(ssh remoto2 "ls /path/to/archive | head -n1")
first_not_needed=$(echo -e "$first_not_needed_1\n$first_not_needed_2\n"
| sort | head -n1)
pg_archivecleanup /path/to/archive $first_not_needed

Exemplo simplório, precisa verificar melhor e tratar erros.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Streaming Replicação

[Matheus de Oliveira]

2015-09-14 12:32 GMT-03:00 Raphael Coutinho <raphael.couti...@dbmax.com.br>:

> diretório onde ficam armazenados os archives, faz um scp para o standby
> remoto e lá o restore command se encarrega de extrair e disponibilizar para
> restauração.
>
> Feito isso, o nosso shell verifica em ambos os Servidores Standby em qual
> segmento eles estão conforme a consulta abaixo:
>
>
> *select pg_last_xlog_replay_location()*
> Sendo assim,  *sabendo o ponto dos dois, pegamos o segmento inferior, e
> removemos tudo para trás.*
>

Como já mencionado, o procedimento está incorreto.

Mas ao invés de fazer isso "na raça", porque não configure o
"archive_cleanup_command" no seu "recovery.conf" [1]?

Recomendo inclusive a utilização do pg_archivecleanup [2], que foi feito
exatamente para isso.

[1]
http://www.postgresql.org/docs/current/static/archive-recovery-settings.html#ARCHIVE-CLEANUP-COMMAND
[2] http://www.postgresql.org/docs/current/static/pgarchivecleanup.html

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] reset do transaction_id

[Matheus de Oliveira]

2015-09-03 18:25 GMT-03:00 Alessandro Lima <grandegoia...@gmail.com>:

> Utilizo o Audit Trigger e percebi que ele gerou dois registros de datas
> bem diferentes com o mesmo transaction_id.
> Obs.: Recentemente foi feito um pg_dump e pg_restore quando trocamos o
> servidor.
>
> Gostaria de saber se o pg_restore reseta o transaction_id,
>

Não, o pg_restore não "reseta" o transaction_id, ele simplesmente não
armazena essa informação.

Se o transaction_id que você se refere foi recuperado pelo resultado da
função txid_current(), então ao restaurar um dump este vai naturalmente
usar o que está definido na nova instância. De qualquer forma você não deve
considerar o txid_current() para identificação dessa forma, porque esse
valor é circular, depois de chegar à 2^31 irá voltar à zero (na verdade é 3
ou 4, não lembro bem).

e o que mais ele pode resetar?
>

Como eu disse, não irá "resetar", mas acontece que nem toda informação é
armazenada, como os OIDs (a não ser que use --oids). Colocando de forma
simples, serão armazenadas informações lógicas (daí "backup lógico"),
detalhes do físicos, como o "transaction_id", visibilidade das transações,
posição do XLOG, etc.; não precisam ser armazenados.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] reset do transaction_id

[Matheus de Oliveira]

2015-09-03 19:18 GMT-03:00 Alessandro Lima <grandegoia...@gmail.com>:

> sim, realmente estou usando o txid_current()
>
> Utilizo o transaction_id para consultar no log todas as operações
> realizadas na mesma transação.
>

Não é uma boa ideia, como eu disse, o txid_current é circular e pode ser
reiniciado em certo ponto.

Você pode usar o conjunto now() (data/hora do início da transação) +
txid_current().


> Teria alguma forma de definir o valor inicial do txid_current() ao
> realizar o pg_restore?
>
>
Não.


> >>Colocando de forma simples, serão armazenadas informações lógicas (daí
> "backup lógico")
> Então utilizando (pg_basebackup + xlogs) o transaction_id será mantido?
>

Sim.

Mas novamente, na operação normal do banco, após 2^31 transações o
txid_current será reiniciado. Use o now() + txid_current() como comentei.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Pesquisa Exata com Full Text Search

[Matheus de Oliveira]

2015-09-02 13:31 GMT-03:00 Renan Fuentes <renancfuen...@gmail.com>:

> Hoje em Produção eu tenho este index:
>
>   CREATE INDEX idx_nome_match
>   ON cliente
>   USING btree
>   (nome::text COLLATE pg_catalog."default" varchar_pattern_ops);
>
>
Além disso, você pode querer:

CREATE INDEX ON cliente (simples(nome) varchar_pattern_ops);

Daí podes fazer busca exata:

EXPLAIN ANALYZE SELECT  nome from cliente where simples(nome) =
simples('JOSE DA SILVA NASCIMENTO');

Ou pelo prefixo:

EXPLAIN ANALYZE SELECT  nome from cliente where simples(nome) LIKE
simples('JOSE DA SILVA NASCIMENTO%');


>
>   Funciona, só que querendo melhorar a performance, por isso, estou
> estudando "Full Search Text",
>


Pra busca exata com o operador =, uma B-tree vai atender muito bem. Pode
nos mostrar os planos das consultas acima?


pois a minha base é grande (190 milhões de rows), e está lenta a pesquisa .
> E pelo testes que fiz até o momento realmente FTS é mais rápido, porém a
> minha dificuldade é a pesquisa exata e também a pesquisa variando, por
> exemplo: pesquisando 'JOSE MARIA DA SILVA', com o FTS retornar, as 'MARIA
> JOSE DA SILVA', etc. O que precisaria é a famosa 'JOSE MARIA DA SILVA%'.
>

Você pode indexar LIKE com B-tree caso o coringa não esteja no começo. Caso
queira usar o LIKE com coringa no começo, então veja a extensão pg_trgm [1].

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

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tempo de execução do backup físico

[Matheus de Oliveira]

2015-08-29 20:58 GMT-03:00 Danilo Silva danilo.dsg.go...@gmail.com:

 Em um cluster com +- 180 GiB, o que deveríamos levar em consideração para
 determinarmos se o tempo do backup físico (utilizando rsync) está elevado
 ou não?

 Semana passada, levou 3 horas, hoje, levou quase 5 horas.


Se é muito ou pouco, depende de vários fatores e qual é gargalo (I/O, CPU,
rede, ???). Como exatamente é seu processo de backup? Local ou remoto?
Quais parâmetros do rsync?


 Se utilizar o pg_basebackup ao invés do rsync, terei ganho de tempo?


Acho difícil, mas tente, mesmo que leve um pouco mais que o rsync, eu
recomendo, porque o pg_basebackup é mais confiável (não que o rsync não
seja confiável, mas é fácil errar no processo quando usamos o rsync,
correndo o risco de gerar backups inconsistentes).

Atenciosamente,
-- 
Matheus de Oliveira
___
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: RES: Espelhamento !!

[Matheus de Oliveira]

2015-08-25 10:46 GMT-03:00 Agape World Informática Ltda 
ag...@agapeworld.com.br:

 Infelizmente não tenho como fazer isso.
 Maquinas nas lojas Windows 7.
 Web servidor Linux.
 E não tem como mudar isso, esse é um dos meus grandes problemas.

 Ainda  não sei como proceder para fazer isso funcionar.
 Nem quais ferramentas usar.


Qual a versão do seu PostgreSQL? Se estiver usando a versão 9.4 ou puder
fazer o upgrade, compensa testar o BDR (Bi-Directional Replication) [1]. No
seu caso seria usar como UDR (Uni-Directional Replication) [2].

Outras opções seriam os projetos que implementam replicação baseado em
triggers, como Slony, Bucardo, Londiste, etc.

[1] http://2ndquadrant.com/en/resources/bdr/
[2] http://bdr-project.org/docs/stable/overview-udr.html 
https://wiki.postgresql.org/images/a/a8/Udr-pgconf.pdf

Atenciosamente,
-- 
Matheus de Oliveira
___
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: RES: Matar Usuario Postgresql 8l.2

[Matheus de Oliveira]

2015-08-25 11:17 GMT-03:00 Agape World Informática Ltda 
ag...@agapeworld.com.br:

 Algum usuário tentar conexão no processo.

 Usei o psql abaixo, trava a conexão.

 Só que ai eu também não consigo fazer o processo.

 Trava tudo mundo.


O seu usuário (que está executando essas operações) deve usar outro banco
de dados para conectar-se, você não pode usar a base que está querendo
remover nas suas conexões.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Diferença condicional para campos boolean

[Matheus de Oliveira]

2015-08-25 15:13 GMT-03:00 Danilo Silva danilo.dsg.go...@gmail.com:

 WHERE campo_boolean IS TRUE

 WHERE campo_boolean = TRUE


IS e = tem diferença, mas na cláusula WHERE o efeito vai ser o mesmo.
Explico:

`campo_boolean = TRUE` pode retornar 3 valores:
- TRUE (verdadeiro) caso campo_boolean seja TRUE
- FALSE (falso) caso campo_boolean seja FALSE
- NULL (nulo) caso campo_boolean seja NULL

Enquanto `campo_boolean IS TRUE` pode retornar 2 valores somente:
- TRUE (veradeiro) caso campo_boolean seja TRUE (igual ao = )
- FALSE (false) caso campo_boolean seja FALSE **ou** caso campo_boolean
seja NULL

Resumindo, ambos tratam o NULL de forma diferente, e IS nunca irá retornar
NULL.

Agora, o efeito vai ser o mesmo no WHERE porque quando retorna-se NULL numa
expressão do WHERE é equivalente à ter retornado FALSE. Cuidado, isso não
quer dizer que NULL seja equivalente à FALSE, isso depende do contexto,
numa cláusula CHECK, por exemplo, retornar NULL é equivalente à TRUE, ou
seja, o efeito é ignorar a verificação (ignorar a linha no WHERE, ignora a
checagem do CHECK).

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Matar Usuario Postgresql 8l.2

[Matheus de Oliveira]

2015-08-24 18:10 GMT-03:00 Agape World Informática Ltda 
ag...@agapeworld.com.br:

 Como faço  para parar todos os usuarios do banco postgresql 8.2


Em 2015 e você usando a versão 8.2? Tem gente que gosta de sofrer mesmo...
xP


 Não estou achando.



 Tenho que fazer o seguinte.



 - drop no banco.

 - create

 - restaurar o banco.


Ah... Mais uma coisa que esqueci de mencionar e vou deixar aqui como
referência. O que passamos aqui vai funcionar para a grande maioria dos
casos, mas tem uma situação bem específica (e bem chata) onde um usuário
pode conectar entre o kill e o DROP DATABASE. Mesmo renomeando a base isso
pode acontecer em versões mais recentes por causa do autovacuum. Uma forma
de se resolver isso é desabilitar a possibilidade de conexão na base
fazendo um UPDATE na pg_database:

UPDATE pg_database SET datallowconn = false WHERE datname =
'nome_da_base';
-- Fazer o `kill -TERM pid`
DROP DATABASE nome_da_base;
... faz o CREATE e a restauração aqui ...

Quanto à parte do kill manual na 8.2, você pode fazer via shell:

$ psql -c UPDATE pg_database SET datallowconn = false WHERE datname =
'nome_da_base';
$ psql -AXtqc SELECT procpid FROM pg_stat_activity WHERE datname =
'nome_da_base'; | xargs kill -TERM

*ATENÇÃO:* em geral não é recomendado fazer atualização em tabelas de
catálogo, mas sabe-se que as colunas datallowcon e datistemplate da
pg_database são seguras de atualizar, tanto que na versão 9.5 criou-se as
opções ALLOW_CONNECTIONS e IS_TEMPLATE no comando ALTER DATABASE para fazer
essa operação, assim, na 9.5, ficaria:

ALTER DATABASE nome_da_base WITH ALLOW_CONNECTIONS=false;
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname =
'nome_da_base';
DROP DATABASE nome_da_base;

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Interpretação das mensagens de log - PITR

[Matheus de Oliveira]

2015-08-21 19:47 GMT-03:00 Franklin Anderson de Oliveira Souza 
frankli...@gmail.com:

 Tenho me dedicado a estudar o PITR, realizando vários tipos de testes. Em
 um exemplo simples, alimento um banco com dados para gerar arquivos WALs,
 em seguida crio um backup fisico com pg_basebackup e volto alimentar com
 mais dados. Feito isso dou stop no banco, deleto tudo do PGDATA,
 descompacto o base.tar.gz criado pelo pg_basebackup e crio o arquivo
 restore.conf, dou start no banco e tudo volta funcionar normalmente, pois
 posso ver os últimos dados inseridos da ultima carga de dados. Mas no log
 tenho a seguinte mensagem que gostaria que vocês me explicassem o que pode
 ser, segue abaixo:

 DETAIL:  The failed archive command was: test ! -f
 /backup/postgresql/archive/0001000C  cp
 pg_xlog/0001000C
 /backup/postgresql/archive/0001000C
 LOG:  archive command failed with exit code 1


Pelo jeito é o test que está falhando, se o cp estivesse falhando você
veria uma mensagem de erro emitida pelo mesmo (a não ser que tenha removido
a mesma no e-mail). O que significa então que o arquivo
0001000C já deve ter sido arquivado anteriormente. Pode
verificar se o arquivo está lá?

Se o arquivo estiver lá, então creio que aconteceu o seguinte:

1. O 0001000C não estava arquivado ainda quando fez o
backup do servidor primário
2. Você fez um backup incluindo o pg_xlog (e.g. -x ou -X no pg_basebackup),
certo?
3. Ao restaurar o backup e iniciar o novo servidor, o PostgreSQL verificou
(pela archive_status) que esse segmento não tinha sido arquivado, e tentou
fazer o arquivamento. Mas, como este foi arquivado *após* o backup, esse
erro foi apresentado.

Assumindo que estou certo acima. Ainda temos uma questão. O pg_basebackup,
em teoria, devia esperar o arquivamento de todos os segmentos necessários
antes de terminar. O que não causaria essa situação, pode passar o
procedimento que executou tanto no backup como na restauração?

Estou assumindo outra coisa, que o timeline após a restauração foi alterado
(para 2, provavelmente); nesse caso o arquivo 0001000C não
foi gerado por esse novo servidor. Isso está correto?

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Monitoramente IO

[Matheus de Oliveira]

2015-08-21 19:43 GMT-03:00 Cleiton Luiz Domazak cleitondoma...@gmail.com:

 Isso se torna um problema pois em casos como o meu, em que o log está
 configurado para pegar queries acima de 100ms apenas, essas queries
 individualmente não aparecem. Existe alguma ferramenta ou técnica para eu
 identificar essas queries?


pg_stat_statements [1].

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

At.
-- 
Matheus de Oliveira
___
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: GIN e GIST

[Matheus de Oliveira]

2015-08-24 17:10 GMT-03:00 Agape World Informática Ltda 
ag...@agapeworld.com.br:

 Boa tarde.

 Como faço  para parar todos os usuarios do banco postgresql 8.2

 Não estou achando.


Boa tarde.

Peço por gentiliza que envie uma nova mensagem com sua dúvida ao invés de
responder uma existente, isso bagunça o histórico da lista.

Obrigado.


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

Re: [pgbr-geral] Monitoramente IO

[Matheus de Oliveira]

2015-08-21 12:58 GMT-03:00 Raphael Coutinho raphael.couti...@dbmax.com.br:

 Existe alguma ferramenta que eu consiga identificar os processos do
 postgres que estão demandando mais escrita em disco. Utilizo as ferramentas
 de sistema do Linux, iostat, vmstat, iotop. porém queria identificar os
 processos a nível do banco de dados.

 Situação:
 Vários processos rodam em paralelo no servidor, eu quero conseguir
 identificar a carga de IO que o INSERT. Existe algo nesse sentido ?


Usando o iotop, por exemplo, você pode identificar o pid do processo que
está rodando e consultar a view pg_stat_activity para identificar o que o
backend está fazendo.

Se não me engano o pg_activity [1] dá visão de uso de I/O também.

[1] https://github.com/julmon/pg_activity

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Usuario Read-Only Vs Banco Read-Only

[Matheus de Oliveira]

2015-08-18 8:14 GMT-03:00 ngonz...@ig.com.br:

 1) É possivel abrir o Banco em modo read-only? Talvez passando parametros
 na string de conexao. Como?


Uma forma simples, é você alterar o default_transaction_read_only para o
usuário:

ALTER ROLE seu_usuario_readonly SET default_transaction_read_only TO
'on';

 2) Caso positivo, o acesso fica mais rápido?


Em algumas situações bem específicas com transações SERIALIZABLE eu sei que
existe uma melhora, fora isso não acho que terás muito ganho, especialmente
se estiver usando READ COMMITED (o padrão). Talvez alguém mais saiba de
outras situações.

Saiba também que alterar o default_transaction_read_only para o usuário não
vai te garantir segurança, pois está configuração pode ser alterada
posteriormente pelo mesmo, então você deve garantir segurança via
GRANT/REVOKE.

Quando quero criar um usuário read-only, eu costumo criar uma role
container, alterar o ALTER DEFAULT PRIVILEGES (ADP) do(s) schema(s) e
conceder SELECT à todas tabelas do(s) schema(s). Exemplo:

-- cria a role container (não faz login)
CREATE ROLE meu_db_readonly NOLOGIN;
-- altera permissão padrão para tabelas que serão criadas
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO meu_db_readonly;
-- altera permissão das tabelas existentes
GRANT SELECT ON ALL TABLES IN SCHEMA public TO meu_db_readonly;

OBS: O ADP só vai funcionar como esperado caso seja executado (ou use FOR
ROLE) pelo mesmo usuário que será o proprietário dos objetos. E troque
public pelo seu esquema, caso use outro.

Em seguida, para todo usuário que for read-only, basta adicioná-lo em
meu_db_readonly:

GRANT meu_db_readonly TO meu_usuario;

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] solução para executar a consulta em postgresql

[Matheus de Oliveira]

On Tue, Aug 18, 2015 at 3:29 PM, Aguiar Magalhaes maga...@yahoo.com.br
wrote:

 update tabela_tot set (nome_cli, tot_ana_1_2014) =
 (select distinct (nome_cli), count(data_analise) as tot_analise from
 tabela_mov
 where date_part('MONTH', data_analise)  7
 and date_part('YEAR', data_analise) = 2014
 and ccs  0
 group by nome_cli);


Pelo que entendi você quer atualizar para cada nome_cli o total. Vejo de
cara duas formas:

1. Usando sub-consulta correlacionada:

UPDATE tabela_tot AS tt
SET tot_ana_1_2014 = (
SELECT count(*) AS tot_analise
FROM tabela_mov AS tm
WHERE tm.data_analise = '2014-01-01'
AND tm.data_analise  '2014-07-01'
AND tm.ccs  0
*AND tm.nome_cli = tt.nome_cli*
);

2. Usando a cláusula FROM:

UPDATE tabela_tot AS tt
SET tot_ana_1_2014 = tm2.tot_analise
FROM (
SELECT tm.nome_cli, count(*) AS tot_analise
FROM tabela_mov AS tm
WHERE tm.data_analise = '2014-01-01'
 AND tm.data_analise  '2014-07-01'
 AND tm.ccs  0
GROUP BY tm.nome_cli
) AS tm2
*WHERE tm2.nome_cli = tt.nome_cli*

OBS1: Veja que mudei para não usar o date_part, é melhor caso tenha índice
em data_analise (o índice ideal seria (nome_cli, data_analise), não me
parece ser necessário incluir ccs).

OBS2: Não testei, verifique se roda por favor.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Select das tabelas do banco de dados e se id not null

[Matheus de Oliveira]

On Tue, Aug 18, 2015 at 1:05 PM, Matheus Ferreira 
mferre...@bklogistica.com.br wrote:

 select

 c.relname,

 a.attname as Column,

 pg_catalog.format_type(a.atttypid, a.atttypmod) as Datatype


, a.attnotnull




 from pg_catalog.pg_attribute a

 inner join pg_stat_user_tables c on a.attrelid = c.relid

 WHERE

 a.attnum  0 AND

 NOT a.attisdropped

 order by c.relname, a.attname




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

Re: [pgbr-geral] Tratamento de erros pl/pgsql

[Matheus de Oliveira]

On Thu, Jul 30, 2015 at 4:04 PM, Matheus Ferreira 
mferre...@bklogistica.com.br wrote:

 ERRO: could not connect to server auditoria_sp

 SQL state: 08001

 Context: comando SQL select * from processo_audit

 função PL/pgSQL func_processo() linha 20 em comando SQL


Dado o SQL state, entre em [1] e procure por ele. No seu caso esse erro é o
sqlclient_unable_to_establish_sqlconnection. Com isso em mãos, basta
tratar a exceção:

BEGIN
seu código
EXCEPTION
WHEN sqlclient_unable_to_establish_sqlconnection THEN
tratamento do erro
END;

[1] http://www.postgresql.org/docs/9.4/static/errcodes-appendix.html

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta complicada

[Matheus de Oliveira]

2015-07-27 20:25 GMT-03:00 Stclara stcl...@gmail.com:

 Gostaria de saber se alguém já recebeu um pedido destes e como conseguiu
 resolver:
 - Uma tabela com os campos nome e cores;
 - Ex:
 nome   cores
 carlos   azul, vermelho, amarelo
 josé   branco, cinza, azul
 antonioamarelo, azul, roxo

 - Agora preciso montar uma consulta que me retorne:

 azulvermelhoamarelo  branco cinza roxo
 carlos   carlos carlos  josé joséantonio
 josé  antonio
 antonio


Tem várias formas, isso é semelhante com conceito de PIVOT ou crosstab. O
problema maior no seu caso é que não tem uma grupo claro. Se você estiver
usando versão 9.4 ou superior, então eu penso na seguinte solução (não sei
dizer se a melhor):

CREATE TEMP TABLE foo(nome text, cor text);

INSERT INTO foo VALUES('carlos', 'azul'),('carlos',
'vermelho'),('carlos', 'amarelo'),('josé',
'branco'),('josé','cinza'),('josé','azul'),('antonio','amarelo'),('antonio','azul'),('antonio','roxo');

WITH nomes AS (
SELECT
array_agg(nome) FILTER(WHERE cor = 'azul') AS azul,
array_agg(nome) FILTER(WHERE cor = 'vermelho') AS vermelho
FROM foo
)
SELECT u.* FROM nomes n, unnest(n.azul, n.vermelho) AS u(azul,
vermelho);

Essa consulta usa duas novidades da versão 9.4, primeiro usa o FILTER para
agregar em arrays os nomes que estão em cada cor, depois usa o unnest com
dois parâmetros (unnest com mais de um parâmetro é da 9.4) que já traz o
resultado exatamente como você espera.

Fiz somente para vermelho e azul, mas é só expandir para as demais cores.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Exclusão de logs antigos

[Matheus de Oliveira]

2015-07-28 12:54 GMT-03:00 Alessandro Lima grandegoia...@gmail.com:

 Procurei na internet mas não encontrei nenhuma configuração que deixe a
 pasta de logs pg_log apenas com determinado número de arquivos ou
 determinado tamanho em GB.


O PostgreSQL irá truncar logs antigos apenas se o nome gerado (após o
rotacionamento) coincide com algum que já exista. Isso proporciona um certo
nível de configuração de rotacionamento, por exemplo, eu costumo usar
bastante a seguinte configuração que fará com que tenha no máximo 7
arquivos de log, e 1 GB no máximo cada, ou seja, máximo de 7GB:

log_filename = 'postgresql-%w.log' # gera o nome baseado no dia da semana
log_rotation_age = '1d'# rotaciona todo dia
log_rotation_size = '1G'   # máximo de 1GB por log
log_truncate_on_rotation = 'on'# trunca ao rotacionar

Como o log_filename gera baseado no dia da semana (Domingo - 0, Segunda -
1, ...) e o log_rotation_age está para 1 dia, o PostgreSQL irá apagar logs
mais antigos que uma semana.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta complicada

[Matheus de Oliveira]

2015-07-28 13:17 GMT-03:00 Tarcisio Martins martins.tarci...@gmail.com:

 Legal a solução mas se existir muitas cores vai ser necessário escrever um
 gerador desse script, senão fica inviável. Além disso, para criar este
 gerador é necessário capturar todas as cores possíveis, o que agrega mais
 complexidade para este cenário da solução.


O PostgreSQL não gera colunas de forma dinâmica, então se quiser adaptar
para um número desconhecido de cores, então vai ter que gerar o SQL
dinamicamente (executando como EXECUTE da PL/pgSQL ou pela aplicação, por
exemplo). Nesse caso eu recomendaria seguir outra abordagem, como o uso de
hstore ou json/jsonb.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_basebackup

[Matheus de Oliveira]

2015-07-28 15:25 GMT-03:00 Danilo Silva danilo.dsg.go...@gmail.com:

 ​Não me recordo, mas para ter somente o pg_basebackup instalado no
 servidor, preciso apenas instalar a contrib? ou terei que efetuar uma
 instalação padrão (completa) do postgres?


Apenas o pacote -client (se não me engano nos Debian-based somente
postgresql-client-common já resolve). O pg_basebackup não está nas
contribs.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Buscar registros duplicados que tenham filhos associados

[Matheus de Oliveira]

2015-07-14 10:33 GMT-03:00 Paulo Vitor Bettini de Albuqerque Lima 
paulovitor...@gmail.com:

 Aí eu
 vou apagar os registros sujos e colocar uma constraint pra evitar
 que essa situação se repita.


Ótima iniciativa... :)

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] REF: Trigger em Tabela Pai-Filho com Rateio.

[Matheus de Oliveira]

2015-07-06 23:40 GMT-03:00 PAULO pa...@visualpsistemas.com.br:

 Lancto - Código_- valor_rateado

 010001 60,00 =count= 1 ou seja, 60 / 1 = 60,00

 020122 30,00 =count= 2 ou seja, 60 / 2 = 30,00

 032421 20,00 =count= 3 ou seja, 60 / 3 = 20,00

 043122 15,00 =count= 4 ou seja, 60 / 4 = 15,00



 Até aqui tudo 100%, então a pergunta que faço é a seguinte:

 Preciso dar um UPDATE em cada lancto para poder atualizar o campo
 valor_rateado, ou seja, no final todos os lancto devem estar com 15,00.

 O problema é que a Trigger pertence a tabela filho, então como posso ir
 atualizando a medida que ou lançando ??


Por que ao invés de você salvar o `valor_rateado` na tabela filha você não
salva isso na tabela pai? Salvar na tabela filha é até uma desnormalização.

Além disso, cuidado com condições de corrida (race conditions), se duas
transações tentarem inserir lançamentos ao mesmo tempo, dependendo de como
controlou sua lógica, vai ter problemas.

Eu faria da seguinte forma, adiciona a coluna `valor_rateado` na tabela
pai, e sua trigger (do tipo *AFTER*) ficará + ou - assim:

BEGIN
-- Garante que ninguém vai alterar o valor_rateado ao mesmo tempo
PERFORM 1 FROM tabela_pai p
WHERE p.codigo_pai = NEW.codigo_pai
FOR UPDATE; -- O FOR UPDATE vai bloquear a tupla, para evitar race
conditions
-- Atualiza o valor_rateado na tabela pai
UPDATE tabela_pai
SET valor_rateado = valor_total / (
SELECT count(*)
FROM tabela_filha f
WHERE f.cod_pai = NEW.cod_pai
)
WHERE p.codigo_pai = NEW.codigo_pai;
RETURN NULL;
END;

Essa trigger vai servir para INSERT e UPDATE, e uma simples modificação
para pegar OLD ao invés de NEW para DELETE.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] bug no pgadmin?'

[Matheus de Oliveira]

2015-07-06 17:46 GMT-03:00 Douglas Fabiano Specht douglasfabi...@gmail.com
:

 font face=arial size=3 color=redFormato de Celular Inv?lido/font

 se eu dar um select no banco no pgadmin vem apenas , se for no psql vem
 o resultado acima..
 PGadmin versao 1.20 de 2/junho/2015


Me parece que esse caractere ? está sendo mostrado mesmo no seu terminal
devido à problemas de encoding, não é nem o psql nem o PostgreSQL que está
fazendo isso, talvez esteja usando configurações incompatíveis (e.g.
cliente_encoding com latin1 e terminal com utf8 ou vice-versa).

Não sei quanto ao pgAdmin entretanto.

Atenciosamente,
-- 
Matheus de Oliveira
___
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: REF: Somar Dias no Timestamp.

[Matheus de Oliveira]

2015-07-06 15:56 GMT-03:00 PAULO pa...@visualpsistemas.com.br:

 Esqueci de comentar que a soma esta vindo de uma variável:

 vdias := 30;

 Esta variável será multiplicada por X, que ira retornar: 30 / 60 / 90  e
 assim sucessivamente.

Simples:

v_vencto := new.data_emissao + (vdias * interval '1 day');

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Timestamp With Time Zone

[Matheus de Oliveira]

2015-07-01 13:38 GMT-03:00 Fernando Cambiaghi cambia...@gmail.com:

 Primeiro, creio que você está um pouco enganado, o PostgreSQL não está
 adicionando uma hora. Isso tudo vai depender de como você está inserindo o
 registro, veja que o tipo `timestamp WITH time zone` armazena o valor
 absoluto, e a conversão ao timezone é feito ao exibir. Dependendo do
 formato usado na inserção, pode-se ou não aparecer essa 1 hora a mais no
 resultado (difícil dizer sem mais detalhes).

 Então Matheus, na verdade eu não sei bem como o insert é feito. Eu
 realizo a transferência dos dados via PipeLine ( Objeto para este fim da
 ferramenta de programação Power Builder ), mas é basicamente ler os dados
 de uma fonte de dados e inserir em outra, como uma ferramenta de ETL, porém
 sem T, pois não transformo os dados. E os dados estão no banco PostgreSQL
 com 01 na hora, pois quando realizo uma consulta do tipo SELECT * FROM
 tabela WHERE campo_timestampz = '20150701' , os registros não são
 localizados, porém, ao alterar a consulta para SELECT * FROM tabela WHERE
 campo_timestampz = '20150701' and campo_timestampz  '20150702'  os
 resultados são apresentados,


Naturalmente.


 e com o campo_timestamp no seguinte formato 2015-07-01 01:00:00-03.
 ...


 Como eu já disse, não. Entretanto, dependendo de como você está
 informando os dados, você pode ter essa impressão. Por exemplo, se estiver
 usando um time zone offset ao invés do nome:

 postgres=# SELECT '2015-02-01 00:00:00-03:00'::timestamptz; -- errado
   timestamptz
 
  2015-02-01 01:00:00-02
 (1 row)

 postgres=# SELECT '2015-02-01 00:00:00
 America/Sao_Paulo'::timestamptz; -- correto
   timestamptz
 
  2015-02-01 00:00:00-02
 (1 row)

 Nas minhas aplicações eu não tenho este tipo de casting, nem poderia por
 enquanto, pois as aplicações ainda são para SGDB's diferentes. As consultas
 são realizadas conforme demonstrei mais acima.


Não é o CAST que é importante, mas sim o formato foi usado. Pegando por
exemplo a data que você passou (2015-07-01), se tivesse sido inserida
exatamente como '2015-07-01', ficaria:

postgres=# SELECT '2015-07-01'::timestamptz;
  timestamptz

 2015-07-01 00:00:00-03
(1 row)

E não com uma hora a mais como você citou. Mas isso só é verdade se a
aplicação que faz a inserção está usando exatamente o mesmo TimeZone que é
usado ao exibir os dados e não informa o TimeZone no literal (como eu fiz
no e-mail anterior). Por isso eu disse que não é o PostgreSQL que está
adicionando uma hora, é o formato da aplicação ou o TimeZone configurado
durante a inserção.

Eu faria o seguinte, converter de `timestamp WITH time zone` para
`timestamp WITHOUT time zone`, verifique se somente nesta conversão os
valores inseridos virão corretos (com meia noite). Caso ainda tenha
problemas, adicione uma trigger para fazer a correção (mas continue com
`timestamp WITHOUT time zone`, me parece melhor nesse caso).

OBS: Eu digo que `timestamp WITHOUT time zone`  é melhor como uma gambiarra
intermediária, o ideal NESSE CASO seria `date`. Na maioria das situações é
recomendado usa `timestamp WITH time zone` ao invés de WITHOUT.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Timestamp With Time Zone

[Matheus de Oliveira]

2015-07-01 11:12 GMT-03:00 Fernando Cambiaghi cambia...@gmail.com:

 1. Como posso contornar essa situação, para que na carga dos dados o
 PostgreSQL não trate horário de verão, mesmo os campos sendo do tipo
 timestampz?


Primeiro, creio que você está um pouco enganado, o PostgreSQL não está
adicionando uma hora. Isso tudo vai depender de como você está inserindo o
registro, veja que o tipo `timestamp WITH time zone` armazena o valor
absoluto, e a conversão ao timezone é feito ao exibir. Dependendo do
formato usado na inserção, pode-se ou não aparecer essa 1 hora a mais no
resultado (difícil dizer sem mais detalhes).


 2. É muito ruim continuar utilizando os campos como timestampz ou eu
 deveria urgentemente alterá-los para timestamp ou ainda para date, visto
 que todas as aplicações teriam que ser testadas devido a declaração de
 variáveis que são tipo datetime?


Eu diria que você deveria urgentemente alterá-los para DATE. Uma etapa mais
suave seria alterar para timestamp, mas eu tentaria DATE somente e
verificaria como a aplicação se comporta, pode ser que não tenha tanta
coisa pra mudar na aplicação.


 3. Ao entrar em horário de verão, o PostgreSQL irá começar a gravar as
 datas com 01?


Como eu já disse, não. Entretanto, dependendo de como você está informando
os dados, você pode ter essa impressão. Por exemplo, se estiver usando um
time zone offset ao invés do nome:

postgres=# SELECT '2015-02-01 00:00:00-03:00'::timestamptz; -- errado
  timestamptz

 2015-02-01 01:00:00-02
(1 row)

postgres=# SELECT '2015-02-01 00:00:00 America/Sao_Paulo'::timestamptz;
-- correto
  timestamptz

 2015-02-01 00:00:00-02
(1 row)

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] REF: Substituir Caracteres com TRANSLATE.

[Matheus de Oliveira]

2015-06-29 17:27 GMT-03:00 PAULO pa...@visualpsistemas.com.br:

 Preciso substituir caracteres em tempo de execução e estou tentando:



 SELECT TRANSLATE(info_fisco, 'var2', '0.65') from cfop where cod_ cfop =
 '5102';



 PERMITE O APROVEITAMENTO DE CREDITO DE ICMS NO VALOR DE R$ *var1*
  CORRESPONDENTE À ALIQUOTA DE *var2*% , NOS TERMOS DO

 ART 23 DA LC 123



 -Primeiro select 100%., no Segundo:



 SELECT TRANSLATE(info_fisco, 'var1', '123.45') from cfop where cod_ cfop =
 '5102';



 Ele arredonda o 123.45 para 123. E ignora os centavos.


Ele não arredonda, acontece que o translate não serve para o que você
quer, e você está completamente errado em tentar utilizá-lo desta forma. No
caso você pode simplesmente usar o replace:

SELECT replace(replace(info_fisco, 'var1', '0.65'), 'var2', '123.45')
...

Veja em [1] para mais detalhes e exemplos dessas funções. Entenda a
translate e veja se não está utilizando-a em outras situações dessa maneira.

De qualquer maneira, o replace dessa forma é bem fraco e geralmente gera
dores de cabeça no futuro, caso tenha var1 ou var2 no meio do texto por
qualquer motivo, vira uma zona. Ou casos piores, como variável foo e
foobar. Eu recomendo você usar a função format [2].

[1] http://www.postgresql.org/docs/current/static/functions-string.html
[2]
http://www.postgresql.org/docs/current/static/functions-string.html#FUNCTIONS-STRING-FORMAT

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] REF: SELECT com EXECUTE.

[Matheus de Oliveira]

2015-06-24 9:24 GMT-03:00 PAULO pa...@visualpsistemas.com.br:

 EXECUTE 'SELECT '|| ufCliente ||' INTO resultado FROM cfop WHERE
 cod_cfop = '||'p_cfop';

 RETURN resultado;


Dois erros:

1. O INTO que você quer é parte do EXECUTE, não do SELECT (da forma como
fez, executaria, mas criaria uma tabela chamada resultado, o que não é o
que queres);
2. O valor da variável p_cfop deve ser embutido no comando.

Ambos os erros são relacionados. Basicamente, o que está no escopo da
função PL/pgSQL não está visível no comando dentro do EXECUTE. O que
recomendo pra você é:

1. Coloque o SQL numa variável, assim facilita debugar e evita erros como
esse;
2. Use a função format para usar identificadores;
3. Use a cláusula USING para passar parâmetros.

Seguindo isso, o comando ficaria:

DECLARE
v_sql text;
...
v_sql := format('SELECT %I FROM cfop WHERE cod_cfop = $1',
ufCliente);
RAISE NOTICE 'SQL: %', v_sql; -- não necessário, só para visualizar
EXECUTE v_sql INTO resultado USING p_cfop;
RETURN resultado;
...


De qualquer forma, eu recomendo fortemente você repensar seu esquema. Não
seria melhor ter uma tabela com (cod_cfop, uf, valor), assim não precisaria
de consulta dinâmica, poderia usar diretamente:


SELECT c.valor INTO resultado

FROM cfop c

WHERE c.cod_cfop = p_cfop

AND c.uf = ufCliente;


Atenciosamente,
-- 
Matheus de Oliveira
___
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: REF: SELECT com EXECUTE.

[Matheus de Oliveira]

2015-06-24 10:01 GMT-03:00 André Ormenese aormen...@gmail.com:

 ufCliente é string e você está tentado armazenar em resultado que é
 integer !!


Não é esse o problema. E por favor, evite top-posting, fica bem complicado
entender do que você está falando... Veja como fiz abaixo:


 Em 24 de junho de 2015 09:49, PAULO pa...@visualpsistemas.com.br
 escreveu:

   Assim vai ?



 EXECUTE 'SELECT '|| ufCliente ||' INTO resultado FROM cfop WHERE
 cod_cfop = ' || p_cfop;





 Já tinha Tentado, retorna o seguinte erro:



 ERRO:  operador não existe: character varying = integer

 LINE 1: SELECT sp  INTO resultado FROM cfop WHERE cfop = 5102

^


Esse erro é na comparação de cfop, que é do tipo varchar, com 5102, que é
um literal inteiro. De qualquer forma eu fico com a solução que tinha
proposta anteriormente, que também resolve esse problema (e do INTO que foi
esquecido aqui).

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] array_agg retornar tipo composto

[Matheus de Oliveira]

2015-06-19 11:55 GMT-03:00 Matheus Saraiva matheus.sara...@gmail.com:

  array_agg((modulo_acessos,liberacao_acessos)::tipoacesso)


 Pois é foi assim que fiz aqui, vou vou dar uma olhada nesse método do
 Xará Oliveira, sempre é bom saber outras formas de resolver um problema.


O meu método é esse aí mesmo. Só usei outra sintaxe para fazer o CAST.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Forma alternativa/otimizada de fazer um select

[Matheus de Oliveira]

2015-06-18 8:56 GMT-03:00 Matheus de Oliveira matioli.math...@gmail.com:

 O que nos leva a 4 abordagens diferentes


Ah. Esqueci de um detalhe, que pode ser importante. Das 4 abordagens,
apenas a sua considera empates, ou seja, para tipos que possuem mais de um
registro com maior data, a sua mostra todos, as demais mostra apenas um
(digamos que aleatório). Na abordagem da window function é possível usar a
função rank ao invés de row_number, pois essa considera empates.

Há uma forma performática de fazer considerando empates e usando o LATERAL,
mas também não muito intuitiva. Você precisa disso?

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral