[pgbr-geral] Escolha consistência, pela equipe do Google Cloud Spanner

[Leandro Guimarães Faria Corcete DUTRA]

https://cloudplatform.googleblog.com/2018/01/why-you-should-pick-strong
-consistency-whenever-possible.html

Para contextualizar, Spanner é o RDBMS relacional da Google,
embora a própria Google tenha dito que não é relacional alegando o
próprio motivo que o faz relacional, a saber que suas tabelas, tendo
obrigatoriamente chaves, são relações; confusamente, a Google alega que
o F1, sendo SQL, é relacional, quando ser SQL implica em que há tabelas
que são sacos, não relações, tornando-o não-(quase-)relacional.


-- 
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

Re: [pgbr-geral] "orientado a banco de dados"

[Leandro Guimarães Faria Corcete DUTRA]

Le jeudi 04 janvier 2018 à 09:35 -0200, ivo nascimento a écrit :
> A validacao de um dado no input é para garantir que durante o flow do
> software ele esteja integro.

Sinceramente não entendi.  O cliente ou programa começa uma transação;
ela só se efetiva se passar pelas restrições de integridade da base. 
Simples.  ¿Ou perdi algo?


-- 
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

Re: [pgbr-geral] "orientado a banco de dados"

[Leandro Guimarães Faria Corcete DUTRA]

Le jeudi 04 janvier 2018 à 09:35 -0200, Fábio Telles Rodriguez a
écrit :
> …escalar horizontalmente um banco de dados dá muito mais trabalho do
> que escalar um servidor de aplicação. Se você tiver muitas regras de
> negócio no seu banco de dados, vai concentrar uma parte maior do
> processamento no servidor de banco de dados e menos no servidor de
> aplicação. Quando você acaba de implantar um sistema novo, está tudo
> tranquilo. Quando o tamanho da base e o número de usuários crescer,
> você vai precisar escalar esse banco de dados. E se a sua regra de
> negócio está concentrada no banco de dados, isso vai acontecer bem
> mais cedo do que o normal. O resultado é ter que trabalhar com
> replicação, cluster, particionamento e outras coisas relativamente
> complexas.
> 
> Claro que em alguns casos colocar a regra de negócio no banco de
> dados ajuda. Para validações complexas, operações em lote e rotinas
> que exigem uma segurança maior no acesso aos dados, fazer tudo em PL
> dentro do bancos ajuda muito. Muito mesmo. Mas se você exagerar, pode
> ficar com um gargalo de CPU que vai lhe custar muito caro.

Perdoem a ampla citação do Teles, mas é que tenho de lidar com vários
pontos dela.

Vejam que o pressuposto acima é que o gargalo será CPU de PLs
(PL/PgSQL, PL/Python, PL/Java, PL/PSM ).

Entretanto, quando falei de colocar as regras na base tentei
deixar claro não ser essa a idéia.

O ideal seria ter o máximo de regras de negócio
declarativamente, na forma de restrições de integridade (tipos,
chaves…); se não der declarativamente, na forma de restrições de
verificação (CHECK CONSTRAINT); só em último caso recorrer-se-ia a
procedimentos armazenados, que esses sim carregam uma penalidade de CPU
significativa.

O que costuma acontecer é um modelo de dados acochambrado que
atrapalha o uso de restrições de integridade; o modelo em si é
ineficiente, e os procedimentos armazenados também.  Mesmo assim, para
situações normais (escalas razoáveis, boa manutenção), ainda costuma
sair mais eficiente que um servidor de aplicações separado, gerando E/S
adicional com latência, por ter de validar informações na base antes de
efetivá-las.  Além de que, estando na forma de restrições de
integridade, não haverá a possibilidade de programas ou usuários
contornarem o servidor de aplicações e introduzindo inconsistências na
base.

Aproveitando, quanto a ter de validar dados na entrada:
geralmente é bem mais econômico para o cliente enviar os dados à base e
lidar com eventuais exceções de restrições de integridade que validar
no cliente, pelos mesmo motivos supracitados, relativos a servidores de
aplicações.

O que realmente pode obrigar uma validação na camada de
apresentação é quando há latência significativa entre ela e a base. 
Uma solução interessante era a do finado Dataphor: ele automaticamente
replicava as validações da base (no caso, um SGBD virtual, mas a idéia
era logo ter se tornado um SGBD completo, o que não ocorreu) para a
camada de apresentação, evitando inconsistências entre validações no
cliente e as restrições de integridade na base.


-- 
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

Re: [pgbr-geral] "orientado a banco de dados"

[Guimarães Faria Corcete DUTRA , Leandro]

2018-01-03 14:34 GMT-02:00 Alessandro Lima :
> Realmente a maioria dos desenvolvedores é contra, mas faço parte do 1%
> Prefiro toda regra de negócio no banco de dados, priorizando a performance

Na verdade, mais do que desempenho, a principal vantagem é a
consistência de dados.  Ainda mais quando se tem o cuidado de manter o
máximo de restrições de integridade no modelo de dados,
preferencialmente declarativamente mas alternativamente na forma de
restrições de verificação (CHECK CONSTRAINTs).  Em grande parte, as
(significativas) vantagens de desempenho decorrem da consistência de
dados ocorrer no próprio SGBD.


-- 
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] PostgreSQL o DBMS do ano do DB engines.

[Guimarães Faria Corcete DUTRA , Leandro]

Maior crescimento de popularidade, embora ainda falte um bocado para
alcançar o terceiro lugar:

https://db-engines.com/en/blog_post/76


-- 
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

Re: [pgbr-geral] Delete

[Leandro Guimarães Faria Corcete DUTRA]

Le lun. 18 déc. 2017 à 17:15, Danilo Silva 
 a écrit :


Qual seria a melhor prática para deletar 20 mil registros em uma 
tabela com 1,5 milhões de registros, vale ressaltar que o campo 
condicional do delete é a pk da tabela:


a) Deletar os 20 mil de uma só vez com a condição "IN" no WHERE;
b) Fazer um loop na aplicação e deletar um por vez;


Lembra que SQL é orientado a conjuntos (baseado no modelo relacional, 
que combina lógica dos predicados com teoria dos conjuntos); 
naturalmente, geralmente será bem melhor trabalhar com conjuntos que 
com iterações de operações individuais.



--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61)  3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   ICQ/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] Qualidade de código do PostgreSQL

[Leandro Guimarães Faria Corcete DUTRA]

https://www.viva64.com/en/b/0542/

Suspeito que a diferença de qualidade a favor do PostgreSQL seja ainda
maior do que o artigo levanta.  Afinal, menos defeitos numa base de
código-fonte maior (e mais capaz) representam qualidade mais do que
proporcionalmente ao tamanho da base de código.


-- 
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

Re: [pgbr-geral] Definição

[Leandro Guimarães Faria Corcete DUTRA]

Le ven. 24 nov. 2017 à 19:09, Marcio A. Sepp 
 a écrit :
o campo c2t2 ele eh a chave natural para a tabela. Soh pensei em 
talvez utilizar os dois campos na chave por motivo de acoplamento 
para as tabelas que se referenciarem a t2


Então realmente está errado.  Uma chave natural deve ser a primária, 
geralmente; de qualquer maneira, declarar uma chave que inclua a 
primária e mais atributos é um erro grave.  Basta declarar o outro 
atributo como chave estrangeira para a outra relação (tabela).



--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61)  3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   ICQ/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

Re: [pgbr-geral] Definição

[Leandro Guimarães Faria Corcete DUTRA]

Le vendredi 24 novembre 2017 à 15:58 -0300, Tiago Brasil a écrit :
> 
> create table t2
> ( c1t1 integer,
>   c2t2 integer,
>   c3t2 integer,
> primary key (c1t1, c2t2),
> foreign key (c1t1) references t1 (c1t1),
> unique (c2t2)); **n necessita dessa linha visto que primary key ja
> sao unique e not null por padrão

Não, no caso o que é chave primária é a combinação dos dois atributos. 
O que está curioso é que um desses atributos também é chave; isso
parece estranho, mas não é simples redundância: que dois atributos
sejam chave não significa que um deles isoladamente também o seja.


-- 
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

Re: [pgbr-geral] Definição

[Leandro Guimarães Faria Corcete DUTRA]

Le vendredi 24 novembre 2017 à 16:46 -0200, Márcio A. Sepp a écrit :
> 
> create table t2
> ( c1t1 integer,
>   c2t2 integer,
>   c3t2 integer,
> primary key (c1t1, c2t2),
> foreign key (c1t1) references t1 (c1t1),
> unique (c2t2));

Chave primária (PRIMARY KEY) e alternativa (UNIQUE) são conceitualmente
equivalentes — ambas são chaves candidatas.

Assim, pergunto-me se faz sentido que uma chave composta também
contenha uma outra chave; em outros termos, que uma chave composta seja
constituída de uma chave (c2t2) e mais outro atributo (c1t1).

Como teu modelo está com nomes opacos (não significativos) e
não está comentado, não consigo entendê-lo.


-- 
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

Re: [pgbr-geral] Sobre a história dos bancos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2017-10-30 10:56 GMT-02:00 centrisco...@gmail.com :
> Isso não lembra o lema da Microsoft fim anos 1980 e 1990? Abraçar e
> estender?

Nunca foi um lema oficial, de acordo com a Wikipédia
, mas
nunca deixou de ser uma realidade.  Se ainda usam a frase
internamente, boa questã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] Re : Sobre a história dos bancos de dados

[Leandro Guimarães Faria Corcete DUTRA]

Le vendredi 27 octobre 2017 à 17:55 -0200, Fábio Telles Rodriguez a
écrit :
> 
> Olha, muita coisa mudou depois que o Steve Balmer saiu do comando.

‘Façamos a revolução, antes que o povo a faça’…


> Se você olhar os lançamentos da Azure vai ver que a Microsoft não
> apenas tem investido pesado nisso, como tem tido muito êxito.

Infelizmente.


> Eles até tem serviços gerenciados com Postgres e MySQL agora...

Embrace, extend, extinguish.

Tudo visa a preservar o monopólio MS Windows & Office.  Minha
esperança é que o LibreOffice online ajude a quebrá-lo, conjugado ao
Android.  E que de algum modo isso venha a popularizar as idéias da
FSF.  Senão, o PostgreSQL é especialmente vulnerável a longo prazo, não
estando sob esquerdo de cópia.


-- 
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] Re : - trabalhando com union

[Leandro Guimarães Faria Corcete DUTRA]

Le mercredi 04 octobre 2017 à 17:36 -0300, Felipe Moura a écrit :
> 
> A ideia é montar uma view usando union que busque pessoas ou unidade
> então ficaria algo assim
> 
> SELECT CODIGO, NOME, 1 as tipo FROM pessoa
> UNION
> SELECT CODIGO, NOME, 2 as tipo FROM unidade

Isso cria uma anomalia que normalmente evitamos em se tratando de
relações armazenadas (base): o significado do atributo código depende
do valor doutro atributo.

Entretanto, como se trata duma relação derivada (visão), não
vejo maiores problemas.  Enquanto não for usar isso como base para
outras relações, para transações, para operações… para meros relatórios
e consultas, não deve causar nenhuma catástrofe.


> Alguns colegas não acham legal que o campo codigo possa ser tanto
> pessoa quanto unidade e sugeriram que o certo seria algo assim:
> 
> SELECT CODIGO_PESSOA, 0 AS CODIGO_UNIDADE, NOME, 1 as tipo FROM
> pessoa
> UNION
> SELECT 0 AS CODIGO_PESSOA, CODIGO_UNIDADE, NOME, 2 as tipo FROM
> unidade

Você evita o problema apontado acima, já que morre o código genérico;
não sei se vale a pena o trabalho adicional.  Se for base para
transações, por exemplo, seria necessária a clareza adicional, mas de
qualquer maneira misturar dois atributos numa única relação já não
seria recomendável nem como base para outras relações, nem para
operações.

Resumindo, para meras consultas e relatórios, nenhuma das duas
é muito ruim.


-- 
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] Re : converter ascii para utf8

[Leandro Guimarães Faria Corcete DUTRA]

Le mercredi 27 septembre 2017 à 09:38 -0300, Ilton Junior a écrit :
> 
> Tive um problema parecido, so que no meu caso era de ISO8859-1 para
> UTF8, acontece que tinhamos uma infraestrutura desktop baseada na
> Microsoft, e quando migramos pra Linux a base mudou devido o S.O
> Windows usar ISO8859 e o Linux UTF8.

Só um detalhe: ISO 8859-1 é parecido, mas não idêntico ao Win 1252. 
Geralmente funciona, mas pode haver problemas menores (não lembro se
relacionados a € ou algum caracter com sinal diacrítico dalguma língua
menos votada) e não é correto dizer que Microsoft Windows usa ISO 8859.


-- 
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

Re: [pgbr-geral] Configuração de Máquina

[Leandro Guimarães Faria Corcete DUTRA]

Le mardi 11 juillet 2017 à 00:04 +, Arthur Nascimento a écrit :
> 
> profissionalmente, recomendo centos e rhel, dependendo de cada caso.

Não afeta tua posição pessoal, mas parece-me que o consenso, obviamente
extra-oficial, da comunidade PostgreSQL brasileira era pelo Debian por
ser comunitária e integralmente livre (para qualquer valor usual de
livre), sem precisar desses subterfúgios Cent OS e Red Hat; com a óbvia
exceção de quando há um gerente que, não querendo aprender Informática,
faz questão de homologação.

Eu vou com a maioria da comunidade, que coincide com minha
experiência, limitada embora…


> BTW, sabe que as fontes da red hat são públicas, certo? Não são
> livres no sentido legal

Na verdade, são livres sim, e esse é um mérito da Red Hat: embora
precise assinatura para atualizar o sistema por qualquer mecanismo
automático, é justamente ser livre que permite a existência do Cent OS.



-- 
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

Re: [pgbr-geral] Configuração de Máquina

[Leandro Guimarães Faria Corcete DUTRA]

Le lundi 10 juillet 2017 à 20:47 +, Arthur Nascimento a écrit :
> 
> A melhor é aquela que você (ou a sua equipe) domina.

Vero.


> Nesse ponto eu prefiro centos/rhel (pela documentação e suporte da
> RH)

Lembrando que a Red Hat não suporta o CentOS, e que além da comunidade
há várias empresas que suportam Debian — o que vale também para os
*BSDs, em menor grau.


> (Pessoalmente eu prefiro distros source based e rolling release, mas
> profissionalmente é outra história.)

O Debian testing funciona como atualizações contínuas (/rolling
release/), e todas as livres (o que exclui o Red Hat) são baseadas em
código-fonte — mas as que compilam na instalação dão uma dor de cabeça
pequena, mas ainda desproporcional aos benefícios, esses sim ínfimos. 
De qualquer maneira, em produção quer-se estabilidade, o que exclui
atualizações contínuas.


-- 
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

Re: [pgbr-geral] Configuração de Máquina

[Leandro Guimarães Faria Corcete DUTRA]

Le lundi 10 juillet 2017 à 14:51 -0300, Beatriz Paixão a écrit :
> Vamos montar uma máquina nova para o nosso banco de dados postgresql
com a versão 9.6 aqui na minha empresa.

Procure, se possível, usar a mais recente versão suportada; segundo htt
p://postgresql.org/ seria a 9.6.3.


> * vocês sabem qual a melhor distribuição Linux usar para o
> postgresql.

Provavelmente a mais popular seja o Debian GNU/Linux, mas creio que
todas têm seus adeptos.  Uma situação particular é a de quem precisa
manter compatibilidade com Red Hat, por exemplo por causa de algum
padrão corporativo ou por necessidade de homologação em determinados
modelos de servidor, caso em que o Cent OS passa a ser uma alternativa.

Além de GNU/Linux, muitos dos desenvolvedores globais do
PostgreSQL usam algum *BSD Unix, principalmente o FreeBSD ou o OpenBSD,
até porque o Postgres nasceu e se desenvolveu no BSD.  Dizem até que
foi o Postgres que demandou muito do desenvolvimentos original do BSD
nos anos setenta e oitenta.


> * as maquinas que tenho aqui com postgres tem disco haid, vou manter
> essa configuração.

Imagino que seja Raid.  como você não disse que nível de Raid, imagino
que seja 5 (o mais popular) ou 1+0, vulgo ‘10’, o único geralmente
adequado a bases de dados.  Se estiver em níveis 0, 2, 3, 4, 5 ou 6,
considere migrar para 1+0 (distribuição sobre pares de espelhos).


> * temos que nos preocupar com mais alguma coisa?

Muitas.  Bases de dados não são triviais.  Embora suas perguntas sejam
perfeitamente razoáveis e comuns, indicam que vocês ainda têm muito a
aprender a respeito; talvez a atual base tenha sido implantada por um
consultor externo?  Eu sugeriria contratar uma consultoria de alguma
empresa ou profissional reconhecido na comunidade (não darei os nomes
aqui por estar bem desatualizado) enquanto forma um profissional
interno para assumir essas responsabilidades.


-- 
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

Re: [pgbr-geral] PostgreSQL com Docker

[Leandro Guimarães Faria Corcete DUTRA]

Le samedi 08 juillet 2017 à 19:32 +, Arthur Nascimento a écrit :
> 04.07.2017, 20:18, "Lucas Viecelli" :
> > Alguém utiliza o PostgreSQL com Docker em um ambiente de produção?
> 
> Tenho alguns serviços ainda com docker em produção, mas me arrependi
> disso já faz tempo e estou gradualmente mudando isso.

https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-fai
lure/



-- 
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

Re: [pgbr-geral] DBF ==> Postgresql (dbf to postgresql)

[Leandro Guimarães Faria Corcete DUTRA]

Le mercredi 28 juin 2017 à 15:58 -0300, André Ormenese a écrit :
> 
> No Freebsd já utilizei o pgdbf (Instalei via ports). Funcionou
> perfeitamente. No Linux não sei se existe.

l@dcf-350092:~$ apt search pgdbf
En train de trier... Fait
Recherche en texte intégral... Fait
pgdbf/testing,unstable,now 0.6.2-1.1+b2 amd64  [installé]
  converter of XBase / FoxPro tables to PostgreSQL

l@dcf-350092:~$ 

É raro algo não existir em GNU/Linux, e geralmente está empacotado para
Debian e (ou) derivados.


--  
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

Re: [pgbr-geral] Agrupar bancos de dados replicado num único Banco

[Leandro Guimarães Faria Corcete DUTRA]

Le vendredi 23 juin 2017 à 11:48 -0300, Ivanelson Nunes a écrit :
> 
> Meus bandos são todos na versão 9.4, então o que tenho hoje de opção
> para replicação lógica que suporte a versão 9.4?

Já te falamos do Bucardo, não?  E creio que há outros que agora me
fogem à memória.


-- 
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

Re: [pgbr-geral] Agrupar bancos de dados replicado num único Banco

[Guimarães Faria Corcete DUTRA , Leandro]

2017-06-21 18:37 GMT-03:00 Ivanelson Nunes :
>
> São todos iguais... Em todos os BD's de origem é o mesmo nome de esquema,
> mesmas tabelas, mesmas colunas, etc

Então o pgLogical não deve funcionar, a menos que se mude isso.
Talvez olhar o Bucardo ou algo semelhante?


-- 
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

Re: [pgbr-geral] Explain retornando valores incorretos

[Leandro Guimarães Faria Corcete DUTRA]

Le sam. 27 mai 2017 à 13:41, Vinicius Segalin  
a écrit :


Sim, mas eu tinha esperança do planejador ter uma noção da 
quantidade de registros.


Normalmente, ele tem, e isso é importante.  Talvez a coleta de 
estatísticas esteja desligada?  Vide 
https://www.postgresql.org/docs/9.6/static/monitoring-stats.html e 
https://www.postgresql.org/docs/9.5/static/sql-analyze.html




--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61)  3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
https://www.postgresql.org/docs/9.6/static/monitoring-stats.html




--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61)  3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   ICQ/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

Re: [pgbr-geral] Kubuntu 17.04 X Postgres 9.6 a luta

[Leandro Guimarães Faria Corcete DUTRA]

Le jeudi 25 mai 2017 à 13:53 -0300, siste...@mvsoftware.com.br a
écrit :
> não faz sentido nem o Kate nem o Sudo mudar o Dono ou Grupo

Concordo!  Mas nunca se sabe.  De qualquer maneira, quem mais poderia
ser?  O próprio PostgreSQL é ainda mais improvável, já que ele não usa
os privilégios de superusuário, que eu saiba; por isso mesmo é que
existe o usuário ‘postgres’.


> ou seja quem está alterando o dono do 
> arquivo me parece o Sudo, se ninguém conseguir me dizer que esse é o 
> comportamento normal do sudo, vou dizer que é um bug "meio grave",
> não muito 
> porque ele não tira a segurança do arquivo, muito pelo contrario ele
> fecha totalmente, mas isso derruba qualquer servidor.

Mas pense pelo outro lado que propus: não faz sentido usar privilégios
de superusuário para editar um arquivo que não precisa desses
privilégios; assim, o caso com o sudo seria mau uso, não defeito…

Mas, como o assunto já rendeu muito, resolvi testar aqui no meu
Debian testing.  Nem GNU Emacs com su -, e com sudo nem gEdit, nem ed
nem nvi fizeram isso, então parece ser uma particularidade ou do
Kubuntu ou de tua configuração.  Aliás, não sei que versão do vi usas —
seria o vim?


> Até você descobrir que ele mudou o dono do arquivo, vai passar horas
> e horas quebrando a cabeça como eu.

Por isso mesmo que agradeci teu relato detalhado!  Para ajudar quem
passar pela mesma situaçã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

Re: [pgbr-geral] Kubuntu 17.04 X Postgres 9.6 a luta

[Leandro Guimarães Faria Corcete DUTRA]

Le mardi 23 mai 2017 à 12:32 -0300, siste...@mvsoftware.com.br a
écrit :
> 
> Eu sempre gosto de usar versões nativas do OS pra evitar transtornos

Legal.  E os pacotes dos repositórios do Debian e derivados são muito
bons, inclusive facilitando coisas como usar várias instalações de
versões diferentes.


> # sudo kate /etc/postgresql/9.6/main/pg_hda.conf
[…]
> quando salvo ele muda o dono e grupo do arquivo pra root

Olha, ou muito me engano, ou isso é problema do Kate ou do sudo, nunca
do PostgreSQL… ou é o comportamento esperado mesmo?  Eu nunca usaria
sudo, que pega os privilégios de superusuário, ainda mais com um
programa relativamente complexo como o Kate, que usa Qt e sei lá mais o
quê.  Até rodo o GNU Emacs como superusuário, mas isso já não é muito
recomendado, a não ser com código auditado — o que não verifico, mas
devia.

O que devias fazer é sempre usar o mínimo de privilégios para
cada tarefa; no caso, editar com o usuário postgres.

E obrigado pelo relato completo!


-- 
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

Re: [pgbr-geral] Kubuntu 17.04 X Postgres 9.6 a luta

[Leandro Guimarães Faria Corcete DUTRA]

Le mercredi 24 mai 2017 à 23:40 -0300, Daniel Gaspary a écrit :
> 2017-05-23 12:32 GMT-03:00  :
> > 4 - Restartava o Postgres
> >    # sudo service postgresql restart
> 
> Não deveria estar usando o systemd e seus sscripts?

Creio que o Kubuntu 17.04 ainda está com o Upstart (se não me falha a
memória) em vez do SystemD?


-- 
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

Re: [pgbr-geral] Kubuntu 17.04 X Postgres 9.6 a luta

[Leandro Guimarães Faria Corcete DUTRA]

Le lun. 22 mai 2017 à 15:27, siste...@mvsoftware.com.br a écrit :


O que acontece é que toda vez que eu salvava os arquivos de 
configuração ele mudava o dono do arquivo para root


Instalaste dos repositórios do próprio Kubuntu?  Isso devia evitar 
maiores problemas.


	De qualquer modo, ainda não sabemos nem como editavas, nem como 
instalaste, nem os sintomas do problema.  Mesmo que já tenhas 
resolvido, é legar dar essas informações para ficar de referência 
para futuros usuários que possam vir a ter o mesmo problema.



--
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

Re: [pgbr-geral] Kubuntu 17.04 X Postgres 9.6 a luta

[Leandro Guimarães Faria Corcete DUTRA]

Le dimanche 21 mai 2017 à 18:28 -0300, siste...@mvsoftware.com.br a
écrit :
> Estou tentando usar o postgres9.6 no Kubuntu 17.04 mas estou tomando
> uma baile...

Usaste os pacotes da distro ou o quê?


> Ele instala, funciona numa boa... quando vou configurar o pg_hba.conf
> e o postgresql.conf e salvo as configurações, dou um restart no banco
> ele ele nao restarta

O que mudaste exatamente, e de que valores para quais outros?  O que
vem nos arquivos de registro de atividades em /var/log?


> O simples fato que mudar o usuario postgres de peer para trust pra
> poder conectar e subir minhas bases ele da pau...

Qual?


-- 
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

Re: [pgbr-geral] Regressão linear, derivadas no postgres

[Leandro Guimarães Faria Corcete DUTRA]

Le 10 mai 2017 11:24:44 GMT-03:00, Artur Zanini  a 
écrit :
>Obrigado  Dikson.
>
>Estou levantando as minhas possibilidades.

O Python é excelente, mas se precisar de algo mais específico de estatística​, 
tem o PL/R.



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691 (Vivo) ICQ/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

Re: [pgbr-geral] Recuperar Base PostgreSQL pasta data

[Leandro Guimarães Faria Corcete DUTRA]

Le 24 avril 2017 08:23:04 GMT-03:00, "Edson F. Lidorio"  
a écrit :
> 
>O problema, era o selinux do CentOS, desabilitei o selinux, apliquei as
>pemissões novamente e o PostgreSQL iniciou normalmente.

Com os problemas catastróficos de segurança recentemente aqui expostos, eu 
pensaria três vezes, antes de desabilitar segurança.



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691 (Vivo) ICQ/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

Re: [pgbr-geral] Configuração

[Leandro Guimarães Faria Corcete DUTRA]

Le 17 avril 2017 11:13:35 GMT-03:00, Antonio Cesar  a 
écrit :
>E agendado para toda noite executar esses comandos:
>vacuumdb -d dbamc001 -fzv
>reindexdb -e -d dbamc001

Nunca faça nada tão drástico sem entender bem as circunstâncias e razões!



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691 (Vivo) ICQ/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

Re: [pgbr-geral] Duvidas com encoding UTF8 x LATIN1

[Leandro Guimaraens Faria Corcete DUTRA]

Le mer. 29 mars 2017 à 10:17, Josué Bragagnolo  a 
écrit :


O melhor sempre eh migrar tudo pra UTF8, mas se não é possível 
atualizar sua aplicação, o melhor acredito que seja manter o SO do 
Servidor postgres em iso também


De maneira alguma.  O servidor pode ficar em UTF-8 (ou algum outro 
Unicode), o que o torna útil para todos os outros usos.  A rigor, até 
a base de dados deve ficar em Unicode, e apenas converter dinamicamente 
com o client_encoding, preservando a capacidade total do Unicode para 
quaisquer outros usos.  As bases costumam ganhar outros usos além da 
aplicação original, e não é sábio deixar que uma aplicação 
original obsoleta crie problemas no futuro.


Se houver necessidade absoluta de algo em ISO 8859, tem de ser o -15, 
nunca o -1, que está obsoleto, conforme artigo que já postei nesta 
discussã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

Re: [pgbr-geral] Duvidas com encoding UTF8 x LATIN1

[Leandro Guimaraens Faria Corcete DUTRA]

Le mer. 29 mars 2017 à 8:55, Luiz Henrique  
a écrit :

Pessoal,

Estou iniciando testes no linux com Postgresql 9.4.Por questões de 
compatibilidade com aplicação Delphi os bancos precisam estar em 
LATIN1.


Confira essa informação, Latin1 (ISO 8859-1) está mais que obsoleto. 
Seu sucessor, além do óbvio Unicode em qualquer codificação, é o 
ISO 8859-15, ou Latin 9 .



Criei o banco em LATIN1. Na console psql aparece o erro ao testar o 
insert abaixo:


insert into pessoa(pes_codpes,pes_nome) values ('50200','GIRÃO');

ERROR:  invalid byte sequence for encoding "UTF8": 0xc3 0x4f


No caso, teu console deve estar em UTF-8, que é a configuração 
padrão do GNU/Linux hoje em dia.




Tem algum parâmetro que eu preciso configurar ?


client_encoding, como já disseram.


--
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

Re: [pgbr-geral] Arredondamento

[Leandro Guimaraens Faria Corcete DUTRA]

Le lun. 13 mars 2017 à 11:10, Arthur Nascimento <tur...@gmail.com> a 
écrit :
On Mon, Mar 13, 2017 at 10:14 AM Leandro Guimaraens Faria Corcete 
DUTRA <l...@dutras.org> wrote:

Le lun. 13 mars 2017 à 9:55, Flavio Henrique Araque Gurgel
<fha...@gmail.com> a écrit :
>
> Eu também levei um minuto pra entender.
> O OP precisa no exemplo que o valor na próxima casa após o
> arredondamento seja "acima de 5".


Parece que o OP quer o arredondamento [1] "half down" ou o "half 
towards zero", enquanto que o round() implementa o "half away from 
zero" para numeric e "half to even" para ponto flutuante [2].

[…]

https://en.wikipedia.org/wiki/Rounding#Comparison_of_rounding_modes


Uau!  Muito obrigado por sanar minha ignorância!



--
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

Re: [pgbr-geral] Arredondamento

[Leandro Guimaraens Faria Corcete DUTRA]

Le lun. 13 mars 2017 à 9:55, Flavio Henrique Araque Gurgel 
 a écrit :


> Porém estão me pedindo para arredondar para acima somente
> quando for acima de 5, por exemplo:

Essa mesma é a definição e o exemplo de round ():

>

Eu também levei um minuto pra entender.
O OP precisa no exemplo que o valor na próxima casa após o 
arredondamento seja "acima de 5".


Eu particularmente não conheço nenhuma função embutida que faça 
isso, mas acho que é fácil escrever uma em 4 ou 5 linhas de 
pl/pgsql, devidamente estática, pra resolver.


Ah!  Bom, se entendi direito agora, acho que quem pediu isso ao 
consulente original não entendeu bem o que é arredondamento, e está 
pedindo para ter problemas depois.


	Como dizem, todo mundo pode fazer bobagens, mas para causar uma 
verdadeira catástrofe um computador ajuda.



--
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

Re: [pgbr-geral] Arredondamento

[Leandro Guimaraens Faria Corcete DUTRA]

Le lun. 13 mars 2017 à 8:58, Ricardo  a 
écrit :


Estou usando o round() para arredondamentos, SELECT ROUND( 1.155, 
2 ).


Porém estão me pedindo para arredondar para acima somente 
quando for acima de 5, por exemplo:



Essa mesma é a definição e o exemplo de round ():

https://www.postgresql.org/docs/9.6/static/functions-math.html

‘round(v numeric, s int) numeric	round to s decimal 
places	round(42.4382, 2)	42.44’


Ou entendi algo errado?


--
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] Google Cloud PostgreSQL

[Leandro Guimaraens Faria Corcete DUTRA]

https://cloud.google.com/sql/docs/postgres/



--
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

Re: [pgbr-geral] importar arquivo cvs

[Leandro Guimaraens Faria Corcete DUTRA]

Le lun. 20 févr. 2017 à 11:59, j...@inbraco.com a écrit :
> Preciso importar arquivos de dentro de minha aplicação, há algum 
comando sql que execute a importação.


Supondo que seja uma pergunta, há:

https://google.com/search?q=postgresql+csv



--
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

Re: [pgbr-geral] Escalabilidade horizontal

[Leandro Guimaraens Faria Corcete DUTRA]

Le mer. 15 févr. 2017 à 16:38, Luiz Carlos L. Nogueira Jr. 
 a écrit :
O que quero resolver é problema de CPU sem mexer na aplicação, 
pois vem de terceiros,


Tem aplicação que não tem como resolver mesmo, só mandando refazer. 
Situação típica é a dum sistema que funciona numa escala menor, e 
que abre o bico ao tentar crescer.  Amiúde o consumo de recursos 
cresce exponencialmente com fatores como cardinalidade das relações 
(tamanho das tabelas), concorrência 


	O SQL não implementa toda a independência de dados proposta pelo 
modelo relacional, portanto os ajustes no modelo de dados, físico e 
lógico, são relativamente restritos mas podem ser úteis: índices, 
chaves, restrições de integridade (não apenas as referenciais) 




Hoje tenho 36 CPUs


36 chips ou 36 núcleos?



e o Load Average e CPU pipocam, travando o servidor de banco.


Mas de que processos?  Faz muita diferença quem consome esses 
recursos: aplicações (PLs como PL/pgSQL, PL/Java ) ou acesso a 
dados, por exemplo.



Eu sei que o armazenamento do RAC Oracle é centralizado (temos essa 
solução também implementada para outras aplicações) e sei que o 
postgres não tem essa estruturade armazenamento centralizado.


Mas já olhaste o XL?  Acho que já te propuseram isso duas vezes…


Por isso comecei jogando a possibilidade de um master-master 
síncrono, pois é o que ainda vejo como uma possibilidade com o 
postgres


Isso é um problema enorme na prática, a menos que você consiga 
particionar os dados.  O que geralmente só é viável se a aplicação 
é tua.




--
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

Re: [pgbr-geral] Escalabilidade horizontal

[Leandro Guimaraens Faria Corcete DUTRA]

Le mer. 15 févr. 2017 à 16:16, Luiz Carlos L. Nogueira Jr. 
 a écrit :


Gostaria que minha aplicação apontasse pra um IP/porta e o Cluster 
fizesse um balanceamento de carga e distribuisse entre os servidores 
(nós) onde estão os bancos .
Quando os servidores de banco estivessem topados, poderia colocar 
mais uma máquina para distribuir melhor o processamento.

Seria uma solução parecida com que a Oracle oferece (RAC)
A aplicação abstrairia de como o banco está (standalone ou vários 
nós de banco). o importante pra ela seria um IP/Porta para conexão.


Luís, esse é o problema do fechamento cognitivo precoce.

	Trocando em miúdos, você diz o que quer fazer, e explica os porquês 
genericamente; não diz exatamente os detalhes de que problemas quer 
resolver, e porquê descartou outras alternativas.


	Por exemplo, o Oracle RAC é conhecido por causar mais problemas do 
que resolve na grande maioria dos casos; casos em que as soluções 
verdadeiras estão noutros aspectos do sistema, desde modelagem de 
dados até gestão de risco, passando por perfis de execução de 
aplicação, análise de planos de execução, planejamento de 
capacidade, monitoramento 


	Infelizmente, a Oracle e vários jornalistas especializados, para não 
falar de bloqueiros e pitaqueiros em geral, vendem determinadas 
arquiteturas de sistema como panacéias, o que engana muitos usuários 
a crerem que basta comprar ou implementar algo, sem jamais entender 
requisitos, situações, limitações, funcionamento 


	Veja também que o RAC não se encaixa perfeitamente em tua 
descrição; o RAC trabalha com E/S centralizado, sendo que geralmente 
o gargalo é justamente E/S.  Ou seja, o RAC não é verdadeiramente 
distribuído, no sentido de que não particiona nem replica 
informações, mas depende de uma única unidade de armazenamento 
centralizada.  Em outras palavras, o RAC será útil mais quando o 
gargalo for processamento (CPU) ou memória, casos em que geralmente 
há soluções mais baratas e mais simples, desde otimização do 
modelo e dos programas aplicativos até servidores mais parrudos; e, 
sendo mais simples, mais confiáveis.


	Na prática, nunca vi uma questão dessas se resolver por lista de 
discussões; sempre é algo que se resolve ou por aprendizado e 
experiência do usuário, que eventualmente aprende a analisar o 
sistema como um todo (desde infraestutura até interface de usuário), 
ou mais freqüentemene com consultoria local, em que o prestador de 
serviço tem condições de levantar todas as informações 
necessárias.


	A vantagem do PostgreSQL especificamente, e de sistemas livres em 
geral, é termos implementação livre ou pelo menos gratuita de 
várias dessas ‘soluções’ comumente propostas, o que permite ao 
usuário instalá-las e aprender ‘chutando os pneus‘, o que não é 
ideal mas é sempre um aprendizado útil, e por vezes necessário; 
nesse sentido, veja se o PosgreSQL XL não é o que você queria.



--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9 9302 2691  ICQ/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

Re: [pgbr-geral] Acessa banco em outra pasta

[Leandro Guimarães Faria Corcete DUTRA]

Le jeu. 9 févr. 2017 à 18:42, Flávio Silveira <f...@terra.com.br> a 
écrit :


On 09/02/2017 18:20, Leandro Guimaraens Faria Corcete DUTRA wrote:
> Le jeu. 9 févr. 2017 à 16:45, Franklin Anderson de Oliveira Souza
> <frankli...@gmail.com> a écrit :
>>
>> o app também, pelo firebird mozilla idem e senão se monitorar 
acaba

>
> O Mozilla Firebird é configurável, ao menos.

Não seria Mozilla Thunderbird?


Claro!  Fui na onda… o que é explicação, não desculpa.



--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61)  3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   ICQ/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

Re: [pgbr-geral] Acessa banco em outra pasta

[Leandro Guimaraens Faria Corcete DUTRA]

Le jeu. 9 févr. 2017 à 16:45, Franklin Anderson de Oliveira Souza 
 a écrit :


Sobre top list,  me perdoem, versão web do  gmail posiciona no topo, 
o app também, pelo firebird mozilla idem e senão se monitorar acaba 
enviando dessa forma...


O Mozilla Firebird é configurável, ao menos.



--
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

Re: [pgbr-geral] Acessa banco em outra pasta

[Leandro Guimaraens Faria Corcete DUTRA]

Le jeu. 9 févr. 2017 à 16:08, Cleiton Luiz Domazak 
 a écrit :


2017-02-09 15:37 GMT-02:00 Franklin Anderson de Oliveira Souza 
:

Diretório é mais correto que dizer pasta ! :D


E o correto é não fazer top list para dizer isso :D. Inclusive é 
realmente pasta, uma vez que o amigo está utilizando Windows, pelo 
que entendi do contexto.


Na verdade, o correto é ignorar essa questão, já que em nada 
contribui para a lista.


	Mas, a rigor, ‘pasta’ é apenas a representação gráfica de um 
diretório em determinados programas, assim qual o sistema operacional 
é irrelevante.



--
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

Re: [pgbr-geral] Perder Dados

[Leandro Guimaraens Faria Corcete DUTRA]

Le mar. 7 févr. 2017 à 8:50, Forsell - Erlon  
a écrit :
a lógica é bem simples, como acima não tem erro de codigo senão 
aconteceria com muito mais frequencia.




Aí é que você pode se enganar.  Bom, primeiro você ainda não disse 
exatamente que versão; relatou uma versão principal 9.1, mas como 
não sabemos se é nível 9.1.0 ou 9.1.24 (só para pegar os exemplos), 
não temos nem como verificar a que defeitos já corrigidos podes estar 
sujeito.  Certamente deves atualizar para 9.1.24, se já não estiveres 
nela, e depois disso resolvido começares a preparar para migrar para o 
nível mais recente da 9.6 ou mesmo já da 10.


	Outra coisa, erro de código não necessariamente é na transação em 
si.  Pode ser noutra parte da aplicação.  Como o erro é recorrente, 
reforço a sugestão do Euler (se não me falha a memória) de auditar 
as operações nas tabelas envolvidas, principalmente DELETE.  Isso é 
algo relativamente fácil de fazer, dá para colocar em produção e 
quase certamente apontará o problema.


	Por exemplo, por vezes usamos um nível de isolamento relativamente 
baixo e, embora não haja erro na transação enquanto mecanismo, nem 
na lógica dela mesma, deixamos de perceber que há um erro lógico em 
outra transação, afetando aqueles mesmos dados depois dela encerrada. 
Embora não seja panacéia, um nível de isolamento mais alto pode 
ajudar a pegar esses erros.  Como o sistema já está em produção, 
não tens esse luxo, mas pode ser um método meio desesperado de testar 
fora da produção.


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

Re: [pgbr-geral] VACUUM FULL

[Leandro Guimaraens Faria Corcete DUTRA]

Le ven. 27 janv. 2017 à 15:51, Danilo Silva 
 a écrit :
Pergunto isso pois estou com problemas de espaço em disco, então 
estamos tentando tirar cada Mb de onde der pra tirar, mas não 
queremos comprometer a eficiência do banco.


Problemas de espaço em disco são perigosíssimos para a 
disponibilidade de um sistema de dados.  Considere outras medidas de 
economia, como por exemplo arquivamento de informações históricas 
(‘arquivo morto’) fora de linha, e (ou) eliminação de algumas 
chaves artificiais (/surrogate keys/, ou identificadores [IDs]) em 
favor de naturais (ainda que compostas)...


___
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 definição

[Leandro Guimaraens Faria Corcete DUTRA]

Le mer. 25 janv. 2017 à 3:59, Jorge Luiz  a 
écrit :
Ao que parece pretende-se checar se o número de caracteres desse 
atributo é igual a 5 ou igual a 7 e se todos são caracteres do tipo 
numérico. Possivelmente pode-se fazer essa checagem de alguma forma 
no banco de dados (não sou profundamente conhecedor do Postgres). No 
entanto sei que, geralmente, um banco de dados está associado a 
alguma aplicação que fornece uma interface para entrada dos mesmos 
(linguagens tais como java/javaEE/JSP/JSF, C/C++, php, python etc). 
Sendo assim, poderia se considerar fazer essa checagem (validação) 
no programa, caso a interface ainda esteja em desenvolvimento. Acho 
que nem tudo precisa ser rigorosamente implementado no banco de 
dados. Por exemplo: validação de CPF pode ser colocada no próprio 
BD (já vi um código assim na internet), mas acho mais fácil 
implementar isso na aplicação


No PostgreSQL, seria mais facil fazer na base, mesmo, devido a todas as 
linguagens de programacao disponiveis.  Por exemplo, pode-se fazer a 
verificacao em tela com uma expressao regular muito simples numa 
restricao de integridade de verificacao (CHECK CONSTRAINT); e o exemplo 
que destes facilmente implementa-se com as bibliotecas de validacao 
Perl, Python   Alem de ser mais facil, tem melhor desempenho que 
qualquer aplicacao, e seria a unica maneira de evitar que outra 
aplicacao ou usuario gere inconsistencias.


___
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 definição

[Leandro Guimarães Faria Corcete DUTRA]

Le mar. 24 janv. 2017 à 23:12, Marcio A. Sepp 
 a écrit :

Peço desculpas, mas não consegui organizar o e-mail direito.


Acontece.  Só procure pensar em quem lerá.


O caso eh que tem um cadastro de itens onde o código do item pode 
vir com 5 ou com 7 dígitos. Quando o item eh de um determinado 
importador ele tem 5 dígitos e qdo eh do mercado interno ele tem 7.

Exemplo d código d produto com 7 dígitos: 0012345.
Exemplo d código d produto com 5 dígitos: 01234

O que eh melhor (ou mais correto a fazer neste caso):
1) crio um campo para identificar a origem (importador "xxx" ou 
mercado interno) e junto esse campo na chave. A chave seria composta 
pelo campo origem e o campo código do item (neste caso integer);


Essa é uma solução interessante.  Se o zero à esquerda não for 
significativo, e se não for o caso de separar esse cadastro em duas 
entidades, pode ser ideal.




2) crio o campo código como sendo varchar(7);


Se os zeros à esquerda forem significativos, por exemplo se essa 
lógica que delineaste acima for não apenas incidental mas uma regra 
de negócio, pode ser a solução ideal, já que nesse caso o atributo 
de origem se depreenderia do tamanho da seqüência de caracteres.


	Mas, pensando melhor, do jeito que explicaste, parece ser uma regra de 
negócio.  Se não houver diferenças noutros atributos (atributos 
preenchidos ou NULL de acordo com a origem, ou de significados 
dependentes da origem), eu creio que manteria como seqüência de 
caracteres.  Mas, se houver diferenças noutros atributos, talvez fosse 
o caso de normalizar.  De qualquer maneira, sendo uma regra de 
negócio, um atributo origem explícito seria redundante com o tamanho 
do código, não?  Independente dele ser armazenado como número ou 
seqüência de caracteres.


	É bem difícil aconselhar modelagem por correio eletrônico, costuma 
faltar informação.



--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691 ICQ/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

Re: [pgbr-geral] Ajuda com definição

[Leandro Guimaraens Faria Corcete DUTRA]

Le mar. 24 janv. 2017 à 18:00, Márcio A. Sepp 
 a écrit :


 > O problema disso é que se eu criar o campo como sendo integer, 
lá

 > pelas tantas corro o risco de dar violação de PK.

 Boiei.  Como assim?


'0012345'::integer = 12345


O que voce quer dizer e' que armazena sequencias de caracteres contendo 
apenas digitos como inteiros?  Se tua regra de negocio diferencia zeros 
'a esquerda, pode ser problema.  Mas, no caso, creio que o correto 
seria dizer que e' caracter com uma restricao de integridade de 
conferencia, talvez com uma expressao regular [0-9]* ou algo assim 
(estou enferrujado com as expressoes regulares, e muito mais coisas 
alias).  Se e' que entendi direito.





 > As soluções possíveis seriam criar o campo como varchar(7) ou 
colocar

 > um segundo campo na chave para identificar a informação.

 Acho que veio algo truncado.  Nao me fez sentido.


Ficou estranho, mas vc já respondeu acima. Vou dividir a 
informação em 02 campos integer menores (smallint numa dessas).

Obrigado.

Dúvida resolvida.


Mas esclareca-nos, por favor.


___
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 definição

[Leandro Guimaraens Faria Corcete DUTRA]

Le mar. 24 janv. 2017 à 17:48, Márcio A. Sepp 
 a écrit :


Tenho um caso onde o campo chave da tabela irá receber dois tipos de
informação: integer de tamanho 5 e integer de tamanho 7.


Dois inteiros relativamente pequenos, portanto.


O problema disso é que se eu criar o campo como sendo integer, lá 
pelas

tantas corro o risco de dar violação de PK.


Boiei.  Como assim?


As soluções possíveis seriam criar o campo como varchar(7) ou 
colocar um

segundo campo na chave para identificar a informação.


Acho que veio algo truncado.  Nao me fez sentido.

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

Re: [pgbr-geral] PostgreSQL vs MySQL

[Leandro Guimaraens Faria Corcete DUTRA]

Le mar. 24 janv. 2017 à 15:59, Rafael Fialho  a 
écrit :


Sei que já rolaram muitas discussões aqui sobre esse confronto, 
inclusive quando foi divulgado pela Uber a troca de SGDB, mas 
gostaria de ver com vocês se vocês tem ciência de algum material, 
artigo técnico, lista de vantagens x desvantagens dos dois e etc. 
pra me passar, pra eu poder compilar e repassar para a comunidade 
depois de apresentar este material na empresa onde trabalho.


Procure por MySQL gotchas, se nao me falha a memoria.
___
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: REF: Constraint Check por coluna e por tabela.

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-20 13:09 GMT-02:00 Paulo :
>>Na verdade só o nome difere.  O objeto criado é o mesmo.
>
> Sim, isso eu sei.

Então não entendi qual a dúvida.  Se o objeto criado é o mesmo (uma
restrição de integridade que impede a nulidade dum atributo), e apenas
um tem nome automático e o outro nome atribuído, o que resta a
analisar?


> Mas o comportamento do banco, muda alguma coisa ?

Por que mudaria?  Só por causa do nome da restrição?  É óbvio que é
melhor ter um nome explicitamente definido, mas isso nada tem a ver
com o comportamento nem da base de dados, nem do SBGD.


-- 
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

Re: [pgbr-geral] RES: REF: Constraint Check por coluna e por tabela.

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-20 12:02 GMT-02:00 Paulo :
>
> nome character varying(60) NOT NULL UNIQUE,  aqui
[…]
> CONSTRAINT uq_nome UNIQUE (nome ))   aqui

Na verdade só o nome difere.  O objeto criado é o mesmo.


-- 
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

Re: [pgbr-geral] REF: Constraint Check por coluna e por tabela.

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-20 11:05 GMT-02:00 Paulo :
>
> Qual a principal implicação no banco e na APP entre uma CONSTRAINT CHEK a
> nível de coluna e por tabela ?

Paulo, eu particularmente acho muito difícil responder uma pergunta
tão geral.  Poderias ser mais específico, talvez com exemplo e questão
direta?


-- 
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

Re: [pgbr-geral] not null if

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-19 23:49 GMT-02:00 Tiago José Adami :
>
> Como disse o Dutra, toquemos o barco, e esqueçamos o ocorrido.

Entendido agora, obrigado!  Fiquei preocupado de ter entendido algo
errado e estar dando conselho inadequado.  Boa sexta para todos, e que
ninguém precise ficar de babá de servidor no fim de semana!


-- 
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

Re: [pgbr-geral] not null if

[Leandro Guimarães Faria Corcete DUTRA]

Le jeu. 19 janv. 2017 à 18:45, Alexsandro Haag 
<alexsandro.h...@gmail.com> a écrit :

Em 19/01/2017 18:15, Guimarães Faria Corcete DUTRA, Leandro escreveu:
Acredito não ser um problema de entendimento das formas normais, a 
sua
primeira resposta ao OP deu a entender que apenas com a 
normalização o

problema descrito seria resolvido sem a necessidade de implementar
regras adicionais. Agora está claro. Agradeço pela atenção.

Acho que agora eu quem boiei, mas toquemos o barco!
É que para a questão levantada, a solução por normalização 
permitiria deixar o campo sempre "not null", pois estaria em uma 
tabela que seria preenchida apenas se a o campo da outra tabela fosse 
marcado. Assim o modelo de dados estaria bem definido, sem 
necessidade de constraint adicional, mas apenas regra de negócio da 
aplicação.


Sim, esse era meu ponto.  Não entendi, Alexsandro, o que o colega não 
havia entendido.  Mas tudo bem, toquemos o barco…




--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61)  3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   ICQ/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

Re: [pgbr-geral] not null if

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-19 18:09 GMT-02:00 Tiago José Adami :
>
> Acredito não ser um problema de entendimento das formas normais, a sua
> primeira resposta ao OP deu a entender que apenas com a normalização o
> problema descrito seria resolvido sem a necessidade de implementar
> regras adicionais. Agora está claro. Agradeço pela atenção.

Acho que agora eu quem boiei, mas toquemos o barco!


-- 
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

Re: [pgbr-geral] not null if

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-19 16:07 GMT-02:00 Tiago José Adami :
>
> Apesar do OP ter satisfeito sua necessidade, vou insistir nesta
> questão. Não consegui visualizar como 'obrigar' através de uma tabela
> complementar o valor em um atributo ser not null

Talvez não tenhamos sido suficientemente claros.  A idéia não é criar
uma tabela complementar, mas normalizar; em outros termos, pegar uma
situação em que (aparementemente) há mais de uma entidade ‘misturada’
(representada) por uma única relação, e transformá-la em duas (ou
mais) relações, eliminando a possibilidade de anomalias de
atualização.

A tua pergunta dá a entender que você ainda não entendeu bem o que são
as formas normais e a normalização?  Ou foi só mesmo nossas
explicações sobre este caso que não foram claras?


-- 
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

Re: [pgbr-geral] not null if

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-19 10:55 GMT-02:00 Rafael Sousa :
> é possivel colocar um not null apenas se outro campo for por exemplo true ?

Sim, por exemplo com gatilhos, mas não seria um erro de normalização?
Não seria ideal normalizar?  De qualquer maneira, a idéia que já deram
de uma restrição de integridade é bem razoável, talvez até ideal.


-- 
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

Re: [pgbr-geral] Sequence Jump 32

[Leandro Guimarães Faria Corcete DUTRA]

Le lun. 16 janv. 2017 à 22:26, Jonas Teixeira de Freitas 
 a écrit :
Podes não concordar com oque eu falei anteriormente. E ate citar 
trechos da documentação mas se você não quer concordar que há um 
bug no comportamento da sequence quando o servidor sofre uma parada 
inesperada não tenho mais oque dizer.


Isso que escreveste não foi um argumento, até onde entendo.  Leste e 
entendeste o trecho da documentação?  Não precisa acreditar em mim, 
lá está escrito o que tentei explicar.  E não foi apenas a mensagem 
que citaste, esse assunto já foi aventado várias vezes nesta lista e 
em suas antecessoras.  Pode pesquisar.



A Sequence como ja detalhada anteriormente sofre uma grande 
alteração de forma a meu ver muito incorreta, por mais que digas 
que ela não é um sequencial.


A teu ver, mas não a ver do padrão SQL ou do PostgreSQL.


Enfim, se alguém tiver uma sugestão de como resolver esta 
situação, seria muito útil compartilhar. Obrigado a todos pela 
atenção


Já expliquei, use transações e acrescente um ao valor corrente.  Ou 
defina o cache como 1, como a documentação explica.




--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61)  3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   ICQ/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

Re: [pgbr-geral] Sequence Jump 32

[Leandro Guimarães Faria Corcete DUTRA]

Le lun. 16 janv. 2017 à 17:44, Jonas Teixeira de Freitas 
 a écrit :

Desculpe, mas há um bug sim.


Desculpe, mas não entendeste nem a documentação do PostgreSQL, nem o 
padrão SQL, nem a mensagem que citaste.



O postgres incrementa log_cnt quando há um desligamento forçado 
mesmo que não tenha sido usado todos seus values.


Esse é o comportamento esperado, definido e documentado, por quererias 
algo diferente?



E uma sequence tem por padrão gerar numeros sequenciais, assim a 
garantia de ter um numero sequencial fora de sincronia é grande.


Tua informação está incorreta, provavelmente porque atribuíste o 
significado coloquial de seqüência às SEQUENCEs do SQL.  Para ajudar 
a diferenciar, a partir de agora sempre me referirei à estrutura SQL 
como SEQUENCE.


O objetivo da SEQUENCE é somente dar um número não duplicado.  
Geralmente ele é seqüencial no sentido de não haver saltos, e 
dificilmente ele ciclará alcançando o máximo e voltando ao início, 
mas não há garantias nesse sentido.  Leia 
https://www.postgresql.org/docs/9.6/static/sql-createsequence.htmlhttps://www.postgresql.org/docs/9.6/static/sql-createsequence.html 
: ‘with a cache setting of one it is safe to assume that nextval 
values are generated sequentially; with a cache setting greater than 
one you should only assume that the nextval values are all distinct, 
not that they are generated purely sequentially’.


Incidentalmente, o PostgreSQL não tem defeitos (/bugs/) conhecidos.  
Há divergências em relação ao padrão ISO SQL, mas estão 
documentadas e não são defeitos, apenas melhorias a desenvolver.  
Todo defeito comprovado no PostgreSQL gera uma correção imediata e 
publicação de novas sub-versões das versões suportadas.



--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61)  3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   ICQ/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

Re: [pgbr-geral] Sequence Jump 32

[Leandro Guimarães Faria Corcete DUTRA]

Le lun. 16 janv. 2017 à 17:44, Jonas Teixeira de Freitas 
 a écrit :

Desculpe, mas há um bug sim.


Desculpe, mas não entendeste nem a documentação do PostgreSQL, nem o 
padrão SQL, nem a mensagem que citaste.



O postgres incrementa log_cnt quando há um desligamento forçado 
mesmo que não tenha sido usado todos seus values.


Esse é o comportamento esperado, definido e documentado, por quererias 
algo diferente?



E uma sequence tem por padrão gerar numeros sequenciais, assim a 
garantia de ter um numero sequencial fora de sincronia é grande.


Tua informação está incorreta, provavelmente porque atribuíste o 
significado coloquial de seqüência às SEQUENCEs do SQL.  Para ajudar 
a diferenciar, a partir de agora sempre me referirei à estrutura SQL 
como SEQUENCE.


O objetivo da SEQUENCE é somente dar um número não duplicado.  
Geralmente ele é seqüencial no sentido de não haver saltos, e 
dificilmente ele ciclará alcançando o máximo e voltando ao início, 
mas não há garantias nesse sentido.  Leia 
https://www.postgresql.org/docs/9.6/static/sql-createsequence.htmlhttps://www.postgresql.org/docs/9.6/static/sql-createsequence.html 
: ‘with a cache setting of one it is safe to assume that nextval 
values are generated sequentially; with a cache setting greater than 
one you should only assume that the nextval values are all distinct, 
not that they are generated purely sequentially’.


Incidentalmente, o PostgreSQL não tem defeitos (/bugs/) conhecidos.  
Há divergências em relação ao padrão ISO SQL, mas estão 
documentadas e não são defeitos, apenas melhorias a desenvolver.  
Todo defeito comprovado no PostgreSQL gera uma correção imediata e 
publicação de novas sub-versões das versões suportadas.



--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61)  3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   ICQ/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

Re: [pgbr-geral] Sequence Jump 32

[Leandro Guimarães Faria Corcete DUTRA]

Le lun. 16 janv. 2017 à 17:01, Jonas Teixeira de Freitas 
 a écrit :

https://listas.postgresql.org.br/pipermail/pgbr-geral/2010-April/020556.html


Uma ótima descrição do comportamento das seqüências no PostgreSQL, 
como seria de se esperar do Fabrício.




Para o antigo problema de sequence pular 32 registros log_cnt,  
alguém conseguiu alguma solução?


Não há solução possível onde não existe problema algum.  Isso 
não é um problema, é um comportamento esperado e desejável.  Veja a 
explicação na própria mensagem que cistaste.



Alguma forma de conseguir controlar a sequence para evitar que ocorra 
esse salto de numeração.


Nenhuma, esse não é o objetivo das seqüências no padrão SQL, e 
desconheço se é o comportamento nalgum SGBD; se for, desconfio de que 
o tal tenha problemas ou de desempenho, ou de integridade, ou mais 
provavelmente ambos.


Se realmente queres uma seqüência sem saltos, deves evitar SEQUENCEs 
e implementar teu próprio controle.  Basta usar uma transação com 
nível de isolamento adequado para garantir o sucesso de uma simples 
operação +1.




--
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61)  3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   ICQ/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

Re: [pgbr-geral] Backup sem o pg_dump

[Leandro Guimarães Faria Corcete DUTRA]

Le 15 janvier 2017 11:58:58 GMT-02:00, "POWER Informática" 
 a écrit :
>Pessoal vocês sabem de alguma classe PHP, ou algum projeto que realiza 
>backup sem a utilização do "pg_dump" ?

Tipo Barman ?



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691 (Vivo) ICQ/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

Re: [pgbr-geral] NOSQL baseado em PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-05 11:40 GMT-02:00 Vinícius Aquino do Vale :
>
> Recentemente encontrei um Database cuja a interface SQL dele é baseada na do
> PostgreSQL

Pelo jeito, não apenas a interface; parece ser mais um produto
derivado, como já houve (e creio que ainda há) com propostas análogas.
Pelo menos diz diz que é livre, embora eu não tenha verificado se a
licença é de fato livre, e sendo livre se é compatível com a original,
se é esquerdo de cópia (incompatível, mas até preferível em minha
reles opinião), ou algo incompatível.


> e o conceito dele é ser um database SQL

Diz em https://www.cockroachlabs.com/docs/frequently-asked-questions.html
que é chave-valor, e não entendo bem como um chave-valor pode ser SQL,
mas deve ser apenas ignorância minha.

Normalmente o destino desses sistemas derivados é terem suas funções e
vantagens incorporadas a alguma versão futura do PostgreSQL, e nesse
sentido é ótimo que apareçam; na minha opinião, que não é a dos
desenvolvedores do PostgreSQL, essa seria uma vantagem de eventual
migração para um esquerdo de cópia, mas mesmo como está tem funcionado
razoavelmente bem, evitando a tragédia do comuns
.

Seria interessante alguém de fora analisar e comparar tanto com outros
derivativos, quanto com o que se faz e se planeja fazer no próprio
PostgreSQL, e principalmente se eles pretendem contribuir, como e o
quê exatamente.

Reparei que dizem que se inspiraram no Google Spanner
, que apesar do
óbvio erro tanto dos desenvolvedores quanto do artigo da Wikipaedia é
ao menos mais relacional que o SQL, justamente pelo motivo que eles
dizem que o desqualificaria como relacional.  Nesse sentido, apesar
das boas bases tanto de código (PostgreSQL) quanto de inspiração
(Spanner), o resultado seria inferior conceitualmente, justamente por
não ser (¿tão?) relacional, mas mais prático no curto prazo, por ser
mais próximo do ISO SQL e do PostgreSQL.


-- 
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

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-03 16:30 GMT-02:00 Flaudísio Tolentino :
>
> Legal, cara! Espero que tenha sucesso no seu trabalho e admiro sua
> pré-disposição em contribuir de volta, especialmente com algo validado por
> toda a metodologia requerida para um trabalho acadêmico - o que
> definitivamente pode incluir usar uma versão mais antiga de um software.

Bom tocar nesse ponto.  Há um descasamento entre a comunidade e
processos academicos e o processo (e comunidade) do PostgreSQL.  Temos
um caso famoso no Brasil de um professor que desenvolveu uma funçao
potencialmente importante (índices hipotéticos para o otimizador,
viabilizando estimativa de utilidade de índices e até criaçao
automática de índices, se nao me falha a memória), e por causa desse
descasamento essa funçao ficou anos parada.  A equipe academica e a
equipe do PostgreSQL nao conseguiam colaborar; cada um tinha seus
métodos e culturas e nao conseguia investir em ‘andar a segunda milha’
com o outro.

Por isso perguntei se essa idéia já foi aventada com a comunidade.

Nao que somente o que seria aceito pela comunidade tem validade
academica, mas certamente o ideal seria tentar conciliar; minha
impressao (e nao passa disso) é que caberia aos academicos se
inserirem na comunidade e se fazerem aceitos.  Um pouco como o núcleo
Linux trabalha, também.


-- 
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

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-03 15:53 GMT-02:00 Neto pr :
> Pretendo verificar se as modificações realizadas desde a versão 9.0.1
> até a atual, modificaram muito o modelo de custos do postgresql, pois
> o Patch que estou aplicando, modifica funções de custos, para que
> estimativas sejam mais realistas em ambientes com discos SSDs. Caso
> tenha sido alterado algo significativo ai sim pretendo testar em
> versões mais recentes.

Nao é trivial validar desempenho, pela variedade de situaçoes com que
o otimizador tem de lidar.  Nao sei que recursos estao aa tua
disposiçao, mas eu abordaria diferentemente: dado que já há um
trabalho original mas cuja repetiçao é desinteressante (por
potencialmente obsoleto), eu verificaria se os mecanismos que ele
alterou na 9.0.1 permanecem na v10 (em desenvolvimento), e se essas
idéias foram aventadas na comunidade de desenvolvedores do PostgreSQL
desde entao.


-- 
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

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-03 15:46 GMT-02:00 Neto pr :
>
> perdão, mas o seria OP ?

/Original poster/, literalmente ‘publicador original’.  No caso,
consulente original, ou seja, quem começou a discussao.


-- 
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

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-03 13:21 GMT-02:00 Euler Taveira <eu...@timbira.com.br>:
> On 02-01-2017 14:10, Guimarães Faria Corcete DUTRA, Leandro wrote:
>> Pergunto-me qual a validade de experimentar questoes de desempenho
>> numa versao tao obsoleta, sendo que quase todas as versoes do
>> PostgreSQL trazem bons avanços.  Creio que seria mais relevante
>> aplicar isso aa v. 10.
>>
> A vantagem é comparar laranja com laranja; mesmo se você disser que
> 9.0.23 não houve avanços de performance.

Nao fui claro.  Nao penso na 9.0.23 como ‘nova versao’, embora
tecnicamente o seja, mas correçao de defeitos.


> Contudo, concordo com o Dutra que vale a pena experimentar uma versão
> recente (9.6.1) para apresentar valores mais atuais (já que a versão
> 9.0.1 é de 04/10/2010 -- mais de 6 anos atrás).

Aliás, esse remendo que o colega aplicou, nao há discussoes nesse
sentido para algum futuro próximo?


-- 
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

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-01 3:20 GMT-02:00 Neto pr :
> Guimaraes, sobre  patch,  ele implementa o que esta descrito neste paper:
>
> http://dl.acm.org/citation.cfm?id=2236588

Ou seja, altera o otimizador para saber mais a respeito do
armazenamento em memória nao-volátil, certo?


> Estou desenvolvendo uma pesquisa,no qual sera necessario que o
> Postgresql tenha  essas caracteristicas, que o patch prove,
> modificando o codigo fonte  original. Nao posso migrar para  a ultima
> versao do Postgreesql, devido a questoes do meu trabalho de pesquisa,
> tem  que ser o postgreSQL 9.0.1 com o patch aplicado.

Pergunto-me qual a validade de experimentar questoes de desempenho
numa versao tao obsoleta, sendo que quase todas as versoes do
PostgreSQL trazem bons avanços.  Creio que seria mais relevante
aplicar isso aa v. 10.



-- 
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

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-31 21:58 GMT-02:00 Neto pr :
> Eu preciso dessa versão 9.0.1, pois um pesquisador da alemanha me
> enviou, para ajudar na minha pesquisa de Pós-graduação.

Te enviou o quê exatamente?


> O patch altera
> o postgreSQL para diferenciar características  entre HDD e SSD. É para
> fins de pesquisa que estou utilizando.

Como assim?  Não ficou claro, não para mim ao menos.  Continua
parecendo fechamento cognitivo prematuro, quando a pessoa quer a
resposta à pergunta errada.

Está parecendo mais fácil portar para a última versã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

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-31 19:54 GMT-02:00 Neto pr :
>
> Acho que a dúvida é mais relacionada ao S.O. Linux no entanto o
> Posgresql é parte do problema que estou enfrentando.

Acho que terás mais ajuda na lista do SO.  Detalhe, Linux é só o
núcleo; tua dúvida é de uma distribuição GNU/Linux.


> Tenho que compilar o SGBD Postgresql 9.0.1 que tem um Patch para esta
> versão

Como assim?  Versão mais que obsoleta.  Que remendo (/patch/) é esse?
Porque você precisa disso, afinal?  Parece um problema de fechamento
cognitivo prematuro.


> Alguém poderia me auxiliar em como eu poderia instalar compilar o
> Debian 9.0.1 no Debian 8, ou como instalar o gcc 4.7 no debian 8 ? Eu
> estou tentando fazer em uma VM para não desconfigurar o SO instalado
> num servidor HP-ML110, mas após eu fazer o teste com sucesso, irei
> aplicar o procedimento no servidor.

Compile na máquina virtual, nã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

Re: [pgbr-geral] Ref: SQL de Profissoes.

[Guimarães Faria Corcete DUTRA , Leandro]

Le 21 déc. 2016 11:11, "Paulo"  a écrit :
> Alguém conhece ou tem o link de onde posso baixar as profissões em SQL ?

Poderias ser mais preciso e claro?

Se for o que estou pensando, já discutimos longamente nesta lista (ou
sua antecessora no Yahoo, creio) há alguns anos.


-- 
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

Re: [pgbr-geral] Forma de resolver um travamento

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-14 14:37 GMT-02:00 Leonardo Coleraus :
>
> Boa Tarde Amigos,

Em vez de formatar, pode escrever texto simples mesmo, mas escreva
corretamente, com pontuação e, se possível, acentuação.  Fica melhor
para lermos, entendermos e, se pudermos, ajudarmos.


-- 
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

Re: [pgbr-geral] Instalação do PostgreSQL em Mac

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-14 14:25 GMT-02:00 Danilo Silva :
>
> Vocês teriam um tutorial de instalação do postgres no mac (versão yosemite)?
>
> Qual a melhor forma de instalar?

Provavelmente há pouquíssima gente aqui que faz isso.  Eu
particularmente olharia o brew.


-- 
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

Re: [pgbr-geral] LOCALE Portuguese_Brazil.1252 NO LINUX CentOS 7

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-01 12:11 GMT-02:00 Eduardo Az - EMBRASIS <eduard...@embrasis.com.br>:
>
> Em 01/12/2016 11:30, Guimarães Faria Corcete DUTRA, Leandro escreveu:
>>
>> 2016-12-01 10:39 GMT-02:00 Eduardo Az - EMBRASIS
>> <eduard...@embrasis.com.br>:
>>
>> Alguma razão para usar 32 bits?  Em x86, o recomendado é 64.
>>
> A MÁQUINA É 32 BITS

Caramba, há tempos não escuto falar de māquinas 32 bits.  Apesar delas
economizarem memória e serem preferíveis em Risc abaixo de 4 Gio, a
ineficiência da arquitetura x86-32 as tornou obsoletas mesmo com menos
memória.  E em bases de dados, então, que geralmente queremos mais
memória…


>> Mas por quê não usar o sistema de pacotes da distribuição?  Se pedes
>> ajuda, ao menos explique-se.
>>
> Costume de usuário ruindows, gosto de interface gráfica.

Certo, mas veja que isso vai te dar mais trabalho do que os pacotes
nativos a médio e longo prazos.


> Os caracteres acentuados são trocados
> ç vira ¬ , á vira § e assim por diante

Isso está parecendo mais bagunça de configuração de cliente.  Veja que
a codificação tanto na origem quanto no destino é Unicode UTF-8,
portanto não deveria dar problema algum.  As configurações LC existem
apenas para ordenação (/collate/) e para compatibilização com sistemas
legados (Win1252, ISO 8859 ) via conversão de e para Unicode.


> CREATE DATABASE teste
>   WITH OWNER = eduardoaz
>ENCODING = 'UTF8'
>TABLESPACE = pg_default
>LC_COLLATE = 'Portuguese_Brazil.1252'
>LC_CTYPE = 'Portuguese_Brazil.1252'
>CONNECTION LIMIT = -1;

Isso são apenas convenções de cada sistema.  Em sistemas Posix, não
falamos em Portuguese_Brazil.1252, mas em pt_BR.  Mas pode funcionar,
desde que teu SO tenha sido configurado para isso; no caso, costuma
haver um pacote chamado locales ou algo assim, derivado da GNU libc, a
glibc.  Não lembro como é isso no CentOS, eu (e muita gente nesta
lista) uso Debian, onde essas coisa são melhor organizadas e
documentadas.  Só que não dá para misturar codificações.


> https://listas.postgresql.org.br/pipermail/pgbr-geral/2012-March/030100.html

Cara, quatro anos e meio atrás… e você ainda interpretou errado o que
o colega disse.  Ele falou que ia experimentar, e o Flávio pareceu
dizer que MS Win 1252 e ISO 8859-1 equivaliam, mas como podes
verificar em http://www.i18nqa.com/debug/table-iso8859-1-vs-windows-1252.html
isso não procede.


> Corrigi, deu erro, porem diferente:
>
> CREATE DATABASE teste
>   WITH OWNER = eduardoaz
>ENCODING = 'UTF8'
>TABLESPACE = pg_default
>LC_COLLATE = 'pt_BR.ISO-8859-1'
>LC_CTYPE = 'pt_BR.ISO-8859-1'
>CONNECTION LIMIT = -1;
>
> ERROR:  encoding "UTF8" does not match locale "pt_BR.ISO-8859-1"
> DETAIL:  The chosen LC_CTYPE setting requires encoding "LATIN1".
> ** Error **
>
> ERROR: encoding "UTF8" does not match locale "pt_BR.ISO-8859-1"
> SQL state: 22023
> Detail: The chosen LC_CTYPE setting requires encoding "LATIN1".

Exato.  Você está misturando duas codificações diferentes, a ISO 8859
e a Unicode.  Deixe tudo na base em Unicode e configure os clientes e
usuários que precisarem de ISO ou Win.



-- 
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

Re: [pgbr-geral] Recomendações sobre uso de tipos compostos

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-01 11:30 GMT-02:00 Márcio A. Sepp :
>
> Quais os prós e contras de usar tipos compostos em campos da chave primária?

Você quer dizer tipos compostos nas chaves primárias, ou chaves
primárias compostas?

De qualquer maneira, são dois jeitos de usar chaves naturais, o que é
absolutamente necessário.  O que não é absolutamente necessário é que
a chave primária seja natural; em casos extremos, pode ser necessário
usar uma chave artificial além da(s) natural(is).

Talvez se você exemplificasse o que pensou em fazer, e porque temeu
fazê-lo, poderíamos ajudar melhor.


-- 
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

Re: [pgbr-geral] LOCALE Portuguese_Brazil.1252 NO LINUX CentOS 7

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-01 10:39 GMT-02:00 Eduardo Az - EMBRASIS :
>
> Linux CentOS 7, 32 bits

Alguma razão para usar 32 bits?  Em x86, o recomendado é 64.


> Instalei usando o pacote de instalação do EnterpriseDB (OK, sei que tem
> gente que critica, mas, usei esse)

Mas por quê não usar o sistema de pacotes da distribuição?  Se pedes
ajuda, ao menos explique-se.


> quando crio o banco, ele vai padronizado com:

Cria como exatamente?


> ENCODING = 'UTF8'
> LC_COLLATE = 'pt_BR.utf8'
> LC_CTYPE = 'pt_BR.utf8'
>
> Porém, o locale original, do sistema que estava em windows é
> "Portuguese_Brazil.1252" e fez com que as acentuações fossem todas
> distorcidas.

Distorcido como, fazendo o quê?  /Dump/ e /restore/?  Com que
configurações (de linha de comando e de ambiente) do pg_dump e do
pg_restore, se tiver sido o caso?  E por quê você não remove esse
banco e cria um com o local da origem, ou não segue um dos inúmeros
tutoriais que ensinam a converter?


> Já vi que não consigo criar no mesmo locale do windows

Como assim, não consegue?  Tentou como?


> e não estou
> conseguindo setar o banco com
> "pt_BR-ISO-8859-1", que segundo pesquisa, seria o correto.

Que pesquisa foi essa?  Correto como assim?  Não existe correto ou
incorreto, mas mais ou menos adequado.  ISO 8859-1 é obsoleto; o ideal
geralmente é usar UTF-8 na base e cada programa cliente ou usuário usa
o que bem entender, que o UTF-8 dá conta de praticamente tudo.  Se
precisar mesmo de ISO 8859, tem o 8859-15 (se não me falha a memória)
que é praticamente a atualização do 8859-1.  Não acredite em mim,
pesquise o que lhe é mais adequado.  Mas geralmente a dor de cabeça de
mudar de 1252 para 8859 não vale a pena, melhor pular logo para
Unicode.


> Me aparece a
> seguinte mensagem:
>
> CREATE DATABASE teste
>   WITH OWNER = eduardoaz
>ENCODING = 'UTF8'
>TABLESPACE = pg_default
>LC_COLLATE = 'pt_BR-ISO-8859-1'
>LC_CTYPE = 'pt_BR-ISO-8859-1'
>CONNECTION LIMIT = -1;
>
> ERROR:  invalid locale name: "pt_BR-ISO-8859-1"
> ** Error **
>
> ERROR: invalid locale name: "pt_BR-ISO-8859-1"
> SQL state: 42809

Bom, primeiro que não existe pt_BR-ISO-8859-1, mas pt_BR.ISO-8859-1.
Segundo, se a codificação já é UTF-8, para quê ISO 8859 na base?


> Aonde encontrar explicações ou me passarem algumas dicas?

A documentação é ótima, histórico da lista tem muita coisa, e mais
dicas carecem de mais detalhes.


-- 
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

Re: [pgbr-geral] LOCALE Portuguese_Brazil.1252 NO LINUX CentOS 7

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-01 10:39 GMT-02:00 Eduardo Az - EMBRASIS :
>
> Linux CentOS 7, 32 bits

Alguma razão para usar 32 bits?  Em x86, o recomendado é 64.


> Instalei usando o pacote de instalação do EnterpriseDB (OK, sei que tem
> gente que critica, mas, usei esse)

Mas por quê não usar o sistema de pacotes da distribuição?  Se pedes
ajuda, ao menos explique-se.


> quando crio o banco, ele vai padronizado com:

Cria como exatamente?


> ENCODING = 'UTF8'
> LC_COLLATE = 'pt_BR.utf8'
> LC_CTYPE = 'pt_BR.utf8'
>
> Porém, o locale original, do sistema que estava em windows é
> "Portuguese_Brazil.1252" e fez com que as acentuações fossem todas
> distorcidas.

Distorcido como, fazendo o quê?  /Dump/ e /restore/?  Com que
configurações (de linha de comando e de ambiente) do pg_dump e do
pg_restore, se tiver sido o caso?  E por quê você não remove esse
banco e cria um com o local da origem, ou não segue um dos inúmeros
tutoriais que ensinam a converter?


> Já vi que não consigo criar no mesmo locale do windows

Como assim, não consegue?  Tentou como?


> e não estou
> conseguindo setar o banco com
> "pt_BR-ISO-8859-1", que segundo pesquisa, seria o correto.

Que pesquisa foi essa?  Correto como assim?  Não existe correto ou
incorreto, mas mais ou menos adequado.  ISO 8859-1 é obsoleto; o ideal
geralmente é usar UTF-8 na base e cada programa cliente ou usuário usa
o que bem entender, que o UTF-8 dá conta de praticamente tudo.  Se
precisar mesmo de ISO 8859, tem o 8859-15 (se não me falha a memória)
que é praticamente a atualização do 8859-1.  Não acredite em mim,
pesquise o que lhe é mais adequado.  Mas geralmente a dor de cabeça de
mudar de 1252 para 8859 não vale a pena, melhor pular logo para
Unicode.


> Me aparece a
> seguinte mensagem:
>
> CREATE DATABASE teste
>   WITH OWNER = eduardoaz
>ENCODING = 'UTF8'
>TABLESPACE = pg_default
>LC_COLLATE = 'pt_BR-ISO-8859-1'
>LC_CTYPE = 'pt_BR-ISO-8859-1'
>CONNECTION LIMIT = -1;
>
> ERROR:  invalid locale name: "pt_BR-ISO-8859-1"
> ** Error **
>
> ERROR: invalid locale name: "pt_BR-ISO-8859-1"
> SQL state: 42809

Bom, primeiro que não existe pt_BR-ISO-8859-1, mas pt_BR.ISO-8859-1.
Segundo, se a codificação já é UTF-8, para quê ISO 8859 na base?


> Aonde encontrar explicações ou me passarem algumas dicas?

A documentação é ótima, histórico da lista tem muita coisa, e mais
dicas carecem de mais detalhes.


-- 
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

Re: [pgbr-geral] Tabela Percentual alto de Tuplas marcadas como Delete

[Guimarães Faria Corcete DUTRA , Leandro]

2016-11-29 8:36 GMT-02:00 Fernando Franquini 'capin'
:
>
> talvez o cenário, são milhares de deletes e inserts diários, pode ser por
> isso.

Nah, isso aí não é nada.  A menos que sejam INSERTs & DELETEs
extraordinariamente pesados, acontecendo muito concentradamente, e em
momento crítico.  Probablilidade praticamente zero.


> E sim, vinham de uma versão antiguíssima (8.4) do PostgreSQL.

Antiga, mas quando VACCUUM já não devia ser mais problema.  O mais
provável é que na época leram coisas mais antigas ainda, e (como é
extremamente comum) aplicaram sem fundamento.


> Mas sim, farei meu teste, só tenho que planejar bem, pois será direto em
> produção.

Não tens um paralelo?


-- 
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

Re: [pgbr-geral] Postgres-XL e Postgres-BDR

[Leandro Guimarães Faria Corcete DUTRA]

Le 28 novembre 2016 13:52:30 GMT-02:00, Saulo Tadeu  a 
écrit :
>
>gostaria de saber quais empresas, pode ser no exterior ou no Brasil,
>quem utiliza o Postgres-XL e Postgres-BDR.

Os respectivos sítios creio têm essa informação, não?


>Alguém da lista sabe algo sobre o uso desses SGDB's? (melhores
>praticas, dicas, problemas...)

A principal dica é atentar à ótima prática de evitar o problema da inadequação 
da ferramenta à necessidade.  Como estás comparando dois sistemas muito 
diferentes, provavelmente seria melhor descrever tua necessidade antes de 
comparar ferramentas.



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691 (Vivo) ICQ/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

Re: [pgbr-geral] Tabela Percentual alto de Tuplas marcadas como Delete

[Guimarães Faria Corcete DUTRA , Leandro]

2016-11-28 9:16 GMT-02:00 Fernando Franquini 'capin'
:
>
> Sim, está desligado por opção, pois chegaram a conclusão que o AUTOVACUUM
> durante o dia atrapalha (devido o tamanho das tabelas - Mas ainda quero
> realizar uma alteração a acompanhar isso um dia), por isso é feito VACUUM em
> algumas tabelas principais durante a noite (porque é mais rápido) e VACUUM
> FULL no final de semana, sim, temos essa janela.

Geralmente esse tipo de conclusão se baseia nalguma observação falha,
por exemplo, de versão muito antiga, talvez bugada, ou de diagnóstico
incorreto ou incompleto de um problema.  Faça teu teste.


-- 
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

Re: [pgbr-geral] pg_data em uma versão e binarios em outra

[Leandro Guimaraens Faria Corcete DUTRA]

Le mer. 23 nov. 2016 à 12:10, Charles Viana  
a écrit :


Fui atender uma crise de um sistema que eu não faço a gestão. 
Quando fui verificar a pasta data o arquivo PG_VERSION esta com com 
"8.2", mas o binários do postgres estava a 8.4.11.

[...]
Segundo eles o Banco havia sido atualizado mas não consegui 
identificar, se foi feito um pg_upgrade o arquivo PG_VERSION seria 
alterado ?


Alguém me corrija, mas creio que o pg_upgrade só na v. 9.



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

Re: [pgbr-geral] integrar Python e Postgres

[Guimarães Faria Corcete DUTRA , Leandro]

2016-11-11 13:45 GMT-02:00 Douglas Fabiano Specht :
>
> Utilizamos da enterprosedb pela facilidade de instalação, para nossos
> tecnicos de campos nao precisarem ter que atualizar por exemplo varias
> dependencias..(limitação tecnica nossa)

Acho que nao entendi.  Ja disseste isso antes, mas nao consegui captar
em que o Enterprise DB seria mais simples que aptitude install
postgresql.


> Certo, mas de qualquer forma deu certo utilizando o comando:
> #sudo apt-get install postgresql-contrib-9.5 postgresql-plpython-9.5 e
> automaticamente apareceu os pacotes das extensões para serem adicionadas..

Que bom, mas pode ser um risco de erro manter dois sistemas de
instalacao.  De qualquer maneira, se voce vai usar o apt para isso,
poderia usar tambem para o resto, e evitar muita dor de cabeca.

De maneira geral, se voce quer fazer algo mais simples que o apt, e'
porque ainda nao entendeu todos os problemas que ele resolve.


-- 
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

Re: [pgbr-geral] integrar Python e Postgres

[Guimarães Faria Corcete DUTRA , Leandro]

2016-11-11 11:58 GMT-02:00 Douglas Fabiano Specht :
>
> se a instalação foi efetuada pelo executavel (bin) da enterprisedb

Por que?


> e eu
> rodar a instalação dos pacotes pelo comando #sudo apt-get install
> postgresql-contrib-9.5 postgresql-plpython-9.5 ele ja faz a integração com o
> postgres?

Evite misturar dois sistemas de empacotamento.  Prefira sempre os
pacotes de sua distribuicao.  Se nao der para fazer tudo por um so
sistema, entao faca manualmente no sistema que nao permite fazer por
ele o que voce quer; no caso, se nao puder remover os da Enteprise DB
e usar tudo da distro, nem fazer tudo pela Enterprise DB, entao use as
instrucoes do pacote fonte para completar o que a Enterprise DB nao
deixa fazer.


-- 
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

Re: [pgbr-geral] Criar diagrama - modelo relacional

[Guimarães Faria Corcete DUTRA , Leandro]

2016-11-08 18:27 GMT-02:00 Euler Taveira :
> On 08-11-2016 17:23, Ronilson wrote:
>> Existe algum software free que eu possa utilizar para fazer isto?
>>
> Use o SchemaSpy [1].

Ou o pgAutodoc, ou o SQL::Fairy.


-- 
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

Re: [pgbr-geral] plpython

[Guimarães Faria Corcete DUTRA , Leandro]

2016-10-28 13:46 GMT-02:00 Douglas Fabiano Specht :
>
> centOS 6.8
[...]
> /opt/PostgreSQL/9.6/etc/sysconfig/plLanguages.config file

Pelo visto, usas um sistema de empacotamento que nao correponde a tua
distro.  Faz tempo que nao mexo com Cent OS, mas que me lembre e'
infinitamente mais facil usar os pacotes oficiais.


-- 
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] Codd, Edgar F ‘Ted’: A relational model of data for large shared data banks

[Guimarães Faria Corcete DUTRA , Leandro]

https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

Fundamental.


-- 
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

Re: [pgbr-geral] armazenamento de imagens no Banco x File System

[Guimarães Faria Corcete DUTRA , Leandro]

2016-10-24 10:46 GMT-02:00 Eduardo Bohrer :
> Como o amigo Flavio salientou, existem prós e contras.
>
> De bate e pronto o mais recomendado seria deixar fora do banco mesmo.

Não, o que o Flávio disse, e eu concordo, é que não há ‘mais
recomendado’.  A pessoa tem de avaliar sua situação e decidir.

Se não há problemas reais e constatados, melhor deixar como estar.
Havendo problemas, aí podem-se avaliar prós e contras de mudar.  Mudar
sem saber exatamente porquê vai dar problemas novos sem que houvesse
antigos a resolver.

E na dúvida, deixe no banco.  Ele foi feito para resolver problemas,
não para criá-los.


-- 
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

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

[Guimarães Faria Corcete DUTRA , Leandro]

2016-10-19 11:19 GMT-02:00 Izaque Maciel :
>
> Chave artificial.
> É somente uma identificação de número controle interno, não é como um cpf ou
> rg.
> Não entendo bem, mas garantindo a unicidade do campo em questão, no caso o
> "id", já resolve. Obrigado por alertarem.

Enquanto não der outros problemas, tudo bem; mas sem uma chave
natural, você provavelmente nalgum momento terá a mesma informação
várias vezes registrada, só com ids diferentes.  Deve ser um dos
problemas mais comuns em bases de dados hoje.


-- 
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

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

[Guimarães Faria Corcete DUTRA , Leandro]

Não foi o que você perguntou, mas alertando para um problema potencial:


2016-10-18 15:19 GMT-02:00 Izaque Maciel :
>
> 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');

Essa tabela tem chave natural, ou só artificial?  Porque a artificial
não garante unicidade, e se for só ela dará problema mais cedo ou mais
tarde.


-- 
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

Re: [pgbr-geral] PG 9.6 PGADMIN

[Guimarães Faria Corcete DUTRA , Leandro]

2016-10-07 13:55 GMT-03:00 Eduardo Az - EMBRASIS :
> 1) Instalei o pg, via instalador da EDB

Esse instalador inclui o pgAdmin?


> desinstalei, ao reinstalar, o slony
> não se instala, avisando que tem instalação anterior. Diz que vai atualizar,
> mas, dá erro. (unico problema que tive com relação ao pg em si)

Que erro?  Já pesquisou por esse erro em listas de Slony?


> 2) tentar entrar em uma pasta, por exemplo, para fazer restore ou backup e
> ela não abrir, via o pgadmin.

Creio que o ideal é relatar numa lista de pgAdmin, já que ele não faz
parte do PostgreSQL.  Mas pode ser que alguém te ajude aqui também.


> 3) Restore  de banco de dados do pgadmin, está dando erro, explicando:
> -ao usar a opção restore, aparece uma caixa de mensagem com o status. Ela
> não some, apesar de fazer o restore  e os restores que tento fazer depois,
> não são feitos.
> A principio, imaginei ser problemas com meu laptop (32 bits), porém, em
> instalação em outra máquina (64 bits), acontece o mesmo.
> detalhe: desinstalei todo o PG, ao reinstalar e entrar no pgadmin, a caixa
> de mensagem continua lá, como se eu não tivesse feito nada.

Não seria o caso de buscar suporte na EDB, que criou teu instalador?


-- 
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

Re: [pgbr-geral] PostgreSQL 9.5.4 + Windows 10

[Guimarães Faria Corcete DUTRA , Leandro]

2016-10-03 14:59 GMT-03:00 Emanuel Araújo :
>> O WindowXP tem uma limitação de conexões de usuário quando se usa ele como
>> servidor ...
>
> Nao creio que seja um problema de limite de conexoes, ate porque sao poucas
> conexoes que eh usado pelo sistema, tipo < 20.

No MS-WNT Workstation, o limite era dez.


-- 
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

Re: [pgbr-geral] Depuração & pgHero

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-30 16:47 GMT-03:00 Roberto Mello <roberto.me...@gmail.com>:
>
> On Fri, Sep 30, 2016 at 12:45 PM, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> wrote:
>>
>> https://www.justwatch.com/blog/post/debugging-postgresql-performance-the-hard-way/
>
> Excelentes artigos! Grato por compartilhar!

De nada!

E obrigado por confirmar minha impressão.  Estou tão afastado do
traçado que compartilho algumas coisas até para saber se realmente é
tão bom quanto me pareceu.


-- 
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] Depuração & pgHero

[Guimarães Faria Corcete DUTRA , Leandro]

Porque hoje é sexta.

https://www.justwatch.com/blog/post/debugging-postgresql-performance-the-hard-way/

https://github.com/ankane/pghero



-- 
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

Re: [pgbr-geral] Aplicação desktop com banco de dados hospedado em VPS.

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-28 10:33 GMT-03:00 Saraiva Silva :
>
> O aplicativo não é MS Windows é Python+PyQt rodando sobre ubuntu.

Melhor ainda.  Experimente os protocolos modernos, todos gratuitos:
X11, VNC, NX… cada um se adapta melhor a determinadas situações.  Rede
local X11, NX para /modens/, VNC para o intermediário.  Creio que há
mais protocolos ainda, como implementações livres do RDP do MS
Terminal Server, talvez do protocolo do Citrix Metaframe cujo nome
sempre esqueço… falta de opção não é.


> Nunca tive esse cenário antes, mas minha esperança para achar que dará certo
> é baseado no fato de que, se fosse uma aplicação WEB toda hospedada no
> servidor e acessada no escritório através de um navegador, a quantidade de
> dados trafegadas entre o servidor e o terminal no escritório seria maior
> pois não seriam apenas os dados armazenados no banco, mas sim os queries +
> conteúdo html + imagens, etc.

Na verdade, geralmente uma aplicação Web bem feita é relativamente
leve.  Haja visto que usamos todos os dias gMail   Se o servidor
Web estiver próximo ao PostgreSQL, normalmente devia ser suficiente.


> Por se tratar de uma app desktop não existirá conteúdo de interface
> trafegando, apenas dados de queries.

Mas isso é que justamente é o mais pesado.


-- 
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

Re: [pgbr-geral] Aplicação desktop com banco de dados hospedado em VPS.

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-27 21:10 GMT-03:00 Tiago José Adami :
>
> O aplicativo Desktop é MS Windows? Existe a possibilidade de colocar
> tudo em um VPS, até o aplicativo Desktop, rodando via Terminal
> Service? O tráfego das "telas" via Terminal Server é mais eficiente
> que trafegar dados direto "no" banco.

E mais eficiente ainda quando é X11 (Posix), quando temos várias
alternativas de protocolos para fazer isso: X11 ‘nativo’ em redes
locais, NX remoto…


-- 
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

Re: [pgbr-geral] MIGRAÇÃO POSTGRESQL - LINUX (CISC) para o Solaris (RISC) - DESEMPENHO RUIM NO SOLARIS

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-23 16:31 GMT-03:00 Rosana de Oliveira :
>
> Trabalhamos com o PostgreSQL em nossa empresa.
> Precisamos migrá-lo  da  plataforma Linux  (arquitetura CISC) para a
> plataforma Unix (arquitetura RISC).  Após vários testes, estamos em dúvida
> quanto à performance da arquitetura RISC.
> Fizemos vários testes de pg_dump e de desempenho de queries.
> Em todos os testes, a plataforma Unix foi mais lenta do que a plataforma
> Linux.
>
> - Tempo pg_dump  do Linux: 5 horas
> - Tempo pg_dump  do Unix:  7 horas, 6 horas
> - Queries no Unix  - mais lentas

Esses testes são inválidos, por não aproveitarem o paralelismo da
arquitetura Sun Sparc T5.  O conceito dela é de muito mais núcleos que
os Intel, embora cada núcleo individualmente seja possivelmente mais
lento que um núcleo Intel.  Algo parecido, embora menos radical, vale
também para os AMD.

Como o PostgreSQL ainda tem pouco paralelismo interno às consultas, um
teste válido teria de ser um teste em que se simulasse uma carga real
do sistema, com vários usuários e operação simultâneos.  Dependendo do
modelo específico, o T5 terá doze ou vinte núcleos, se não me fala a
memória, cada um dedicado a uma operação diferente simultaneamente.

À medida em que progredir a implementação do paralelismo no PosgreSQL,
esses testes ficarão mais fáceis.


-- 
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

Re: [pgbr-geral] SELECT lento

[Leandro Guimarães Faria Corcete DUTRA]

Le 21 septembre 2016 17:54:00 GMT-03:00, "Mário Reis" 
 a écrit :
>Se fosse firebird te recomendaria uma Store Precedure com Suspend;

Firebird não tem planejador de execução de consultas tão bom quanto o nosso.


>sempre
>tive muito melhores resultados do que com os select mais complexos(que
>em
>teoria deveriam dar o mesmo resultados

Ao contrário, o planejador tem de dar — e, no PostgreSQL, dá — resultados pelo 
menos tão bons quanto os de qualquer outro método, ainda com a vantagem de se 
adaptar a mudanças no sistema — equipamentos, configurações, massa de dados, 
modelo, carga — sem precisar reescrever consultas.


> pena não haver como fazer isso com o postgres.

Porque não precisamos.


>No IBM400 c/SQL400
>também não tem storeprocediures c/suspend por isso  partiamos o
>problema
>maior em problemas mais pequenos muitas fezes com select parciais
>escrvendo
>para ficheiros de trabalho que de seguida eram usados nos query
>seguintes e
>com óptimos resultados.

Mais uma vez, temos planejador melhor que faz isso automaticamente.


>Select's um pouco mais complexos tendem a ser bastante pesados partido
>o
>problema em pedaços mais pequenos a coisa flui com uma velocidade
>considerável.

Para isso temos CTEs.

Não entendi como achaste que ajudavas… inda mais depois que o Euler já apontara 
a necessidade de dois simples índices.





-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691 (Vivo) ICQ/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

Re: [pgbr-geral] Servidor lento

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-17 15:39 GMT-03:00 Antonio Cesar :
> Os discos estão normal.

O que te indicou isso?  top?  sar?  Cadê os planos de execução
problemáticos?  Se não há planos de execução problemáticos ou
mensagens de registro de atividade, impossível ajudar à distância.

Eu sugiro buscar consultoria urgente, pareces precisar de mais ajuda
do que a que podemos dar numa lista de discussões.


-- 
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

Re: [pgbr-geral] Servidor lento

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-17 14:15 GMT-03:00 Antonio Cesar :
>
> O servidor do meu cliente depois de uma queda de energia ficou muito lento

Difícil ajudar assim.  Você ainda nem verificou o básico do básico,
como a carga do sistema (pode não ser o PostgreSQL), que operações
especificamente estão lentas, eventuais planos de execução… não
sabemos nem qual o sistema operacional!


-- 
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

Re: [pgbr-geral] vacuum analyze por tabela

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-16 19:15 GMT-03:00 Luiz Henrique :
>
> Quando saber que preciso executar vacuum analyze individual por tabela ?

Não precisa, deixe o autovácuo trabalhar.


> Que parâmetros / estatísticas procurar para indicar que a tabela merece um
> vacuum ?
> Alguem tem / recomenda um select que lista isso ?

Sobre as exceções, vide o histórico da lista.  Discutimos isso não faz
tanto tempo.


-- 
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