[pgbr-geral] DBA Brasil 1.0

2016-03-29 Por tôpico Fábio Telles Rodriguez 
Senhores, o evento está com a grade no ar em:
http://www.dbabr.com.br/blog/index.php/dba-brasil-1-0/

Inscrições abertas, mas por tempo limitado: o motivo é que já estamos
estourando a capacidade do local que é de 250 pessoas. Então corram.



-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// s
avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres
http://www.timbira.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

2016-03-29 Por tôpico Adilson Domiciano Júnior 

Boa tarde,

Obrigado amigos pelas respostas, já me ajudou bastante.

Att,
Adilson Domiciano Júnior

Em 29/03/2016 16:21, Fabrízio de Royes Mello escreveu:

On 29-03-2016 15:42, Rafael Fialho wrote:

Em 28 de março de 2016 16:10, Franklin Anderson de Oliveira Souza
> escreveu:

 Como eu disse o pg_dump não bloquei as tabelas, segue abaixo o
 primeiro paragrafo da documentação:

 "...pg_dump is a utility for backing up a PostgreSQL database. It
 makes consistent backups even if the database is being used
 concurrently. *pg_dump does not block other users accessing the
 database (readers or writers)*..."


Boa tarde.
Realmente, não bloqueia *intencionalmente* os usuários, porém o pg_dump,
conforme a própria documentação informa, utiliza SELECTS, e estes, para
que o ACID seja mantido, podem promover diversos tipos de bloqueios nas
tabelas que estão sendo processadas.

Pode bloquer não, ele bloqueia, porém é um AccessShareLock que não
impede DML, porém impede DDL.



Na prática, existe a possibilidade de uma tabela ficar indisponível
enquanto está sofrendo o dump, e por isso o colega não está errado ao
informar que usuários ficam com operações bloqueadas.


Sim, se houver uma tentativa de execução de algum DDL na(s) tabela(s)
que está(ão) sendo exportada(s) então você terá um processo em espera.

Att,



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


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

Re: [pgbr-geral] Backup

2016-03-29 Por tôpico Fabrízio de Royes Mello 
On 29-03-2016 15:42, Rafael Fialho wrote:
> Em 28 de março de 2016 16:10, Franklin Anderson de Oliveira Souza
> > escreveu:
> 
> Como eu disse o pg_dump não bloquei as tabelas, segue abaixo o
> primeiro paragrafo da documentação:
> 
> "...pg_dump is a utility for backing up a PostgreSQL database. It
> makes consistent backups even if the database is being used
> concurrently. *pg_dump does not block other users accessing the
> database (readers or writers)*..."
> 
> 
> Boa tarde.
> Realmente, não bloqueia *intencionalmente* os usuários, porém o pg_dump,
> conforme a própria documentação informa, utiliza SELECTS, e estes, para
> que o ACID seja mantido, podem promover diversos tipos de bloqueios nas
> tabelas que estão sendo processadas.

Pode bloquer não, ele bloqueia, porém é um AccessShareLock que não
impede DML, porém impede DDL.


> Na prática, existe a possibilidade de uma tabela ficar indisponível
> enquanto está sofrendo o dump, e por isso o colega não está errado ao
> informar que usuários ficam com operações bloqueadas.
> 

Sim, se houver uma tentativa de execução de algum DDL na(s) tabela(s)
que está(ão) sendo exportada(s) então você terá um processo em espera.

Att,

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Adicionar coluna com default de outro campo

2016-03-29 Por tôpico Victor Fugiwara 
>
> Ocorre que, por baixo, não há como escapar do "update". Você pretende
> fazer isso para ter um alter table mais "performático"? Ele não será, com o
> default, muito mais rápido do que um update com as devidas otimizações
> (desabilitar triggers e etc.), na teoria.
>
>
>> O comando desse formato dá o erro: ERRO:  não pode utilizar referência à
>> coluna na expressão padrão
>>
>> Existe alguma forma de fazer isso sem a necessidade do update?
>>
>
> Talvez haja outra possibilidade, mas como uma coisa é inerente à outra,
> talvez não seja viável. Qual seria o problema que estás enfrentando para
> evitar o update?
>
>
O problema é que a tabela é grande (alguns milhões de registros e 80
colunas) e preciso adicionar 13 campos nela.
Fiz o teste com um caso onde o campo será NOT NULL e terá um valor fixo e
ficou bem mais rápido comparado com dar update posteriormente. Então creio
que tenha sido mais rápido por ser um valor fixo.

Vou verificar se desabilitando as constraints o update fica mais rápido.
Senão vou ver quanto demora pra criar a tabela com a estrutura necessária,
copiar os dados e depois renomeá-la.

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

Re: [pgbr-geral] Adicionar coluna com default de outro campo

2016-03-29 Por tôpico Rafael Fialho 
Em 29 de março de 2016 15:37, Victor Fugiwara 
escreveu:

> Boa tarde pessoal,
>

Boa tarde!

Preciso adicionar um campo em uma tabela, sendo que o valor deste campo se
> baseia na existência de um outro. A ideia seria algo assim:
>

> ALTER TABLE tabela ADD COLUMN coluna boolean DEFAULT (outracoluna IS
> NULL);
>

>
Ou seja, adiciono o campo e seu valor padrão depende do que tem preenchido
> em outra coluna da tabela. A necessidade disso é pra evitar o alter table
> seguido de um update. O valor default seria removido em seguida, essa regra
> seria apenas para a criação desse campo.
>

Ocorre que, por baixo, não há como escapar do "update". Você pretende fazer
isso para ter um alter table mais "performático"? Ele não será, com o
default, muito mais rápido do que um update com as devidas otimizações
(desabilitar triggers e etc.), na teoria.


> O comando desse formato dá o erro: ERRO:  não pode utilizar referência à
> coluna na expressão padrão
>
> Existe alguma forma de fazer isso sem a necessidade do update?
>

Talvez haja outra possibilidade, mas como uma coisa é inerente à outra,
talvez não seja viável. Qual seria o problema que estás enfrentando para
evitar o update?

[]'s
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

2016-03-29 Por tôpico Rafael Fialho 
Em 28 de março de 2016 16:10, Franklin Anderson de Oliveira Souza <
frankli...@gmail.com> escreveu:

> Como eu disse o pg_dump não bloquei as tabelas, segue abaixo o primeiro
> paragrafo da documentação:
>
> "...pg_dump is a utility for backing up a PostgreSQL database. It makes
> consistent backups even if the database is being used concurrently. *pg_dump 
> does
> not block other users accessing the database (readers or writers)*..."
>
>
Boa tarde.
Realmente, não bloqueia *intencionalmente* os usuários, porém o pg_dump,
conforme a própria documentação informa, utiliza SELECTS, e estes, para que
o ACID seja mantido, podem promover diversos tipos de bloqueios nas tabelas
que estão sendo processadas.
Na prática, existe a possibilidade de uma tabela ficar indisponível
enquanto está sofrendo o dump, e por isso o colega não está errado ao
informar que usuários ficam com operações bloqueadas.

Não existe uma forma de evitar isso com o pg_dump, ou ao menos não conheço.
O que existem são outras soluções de backup que podem amenizar estes
problemas, como replicação, por exemplo. Aí vai da sua real necessidade e
possibilidades.

[]'s
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Adicionar coluna com default de outro campo

2016-03-29 Por tôpico Victor Fugiwara 
Boa tarde pessoal,

Preciso adicionar um campo em uma tabela, sendo que o valor deste campo se
baseia na existência de um outro. A ideia seria algo assim:

ALTER TABLE tabela ADD COLUMN coluna boolean DEFAULT (outracoluna IS NULL);

Ou seja, adiciono o campo e seu valor padrão depende do que tem preenchido
em outra coluna da tabela. A necessidade disso é pra evitar o alter table
seguido de um update. O valor default seria removido em seguida, essa regra
seria apenas para a criação desse campo.

O comando desse formato dá o erro: ERRO:  não pode utilizar referência à
coluna na expressão padrão

Existe alguma forma de fazer isso sem a necessidade do update?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Views !

2016-03-29 Por tôpico Lucas Viecelli 
>
> Boa tarde.
>
> Alguem sabe dizer se tem como criar indices em views.
>
>
Você deve pensar em criar índices nas tabelas.. e não pensar em criar na
view.


>
>
> Outra coisa criei uma view , só o select na view é mais lento que o
> próprio select direto no sql.
>
> O que pode ser.
>
>
>
> Executo o mesmo sql no pg_admin e executo o select na view o tempo da view
> demora mais.
>
>
>

Dê uma pesquisada sobre views materializadas[1], acho que pode ser útil
para o seu caso, claro que depende de vários fatores.

1 -
http://www.postgresql.org/docs/current/static/sql-creatematerializedview.html




Atenciosamente.

*Lucas Viecelli*


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

Re: [pgbr-geral] Views !

2016-03-29 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
Por favor prefira texto simples (puro, não formatado, não HTML ou RTF ou ETF).


2016-03-29 15:06 GMT-03:00 Agape World Informática Ltda
:
>
> Alguem sabe dizer se tem como criar indices em views.

Que sentido isso faria, visto que uma visão não tem dados?


> Outra coisa criei uma view , só o select na view é mais lento que o próprio 
> select direto no sql.

Cadê as informações?  Definições de todos os objetos envolvidos,
consultas e planos de execução?



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Views !

2016-03-29 Por tôpico Agape World Informática Ltda 
Boa tarde.

Alguem sabe dizer se tem como criar indices em views.



Outra coisa criei uma view , só o select na view é mais lento que o próprio 
select direto no sql.

O que pode ser.



Executo o mesmo sql no pg_admin e executo o select na view o tempo da view 
demora mais.





---
Este email foi escaneado pelo Avast antivírus.
https://www.avast.com/antivirus
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral