[pgbr-geral] Replicação e ambiente complexo

[Márcio A . Sepp]

Boa tarde lista,


Gostaria de indicação sobre material sobre replicação do banco postgresql e
configuração em ambientes complexos (mais que um servidor de banco). Tenho
lido algumas coisas, porém sou leigo em replicação, por isso se alguém tiver
alguma indicação de um “how-to” – que explique um pouco dos conceitos
envolvidos, vai me ajudar bastante.



Att.
Márcio A. Sepp


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

[pgbr-geral] RES: Replicação e ambiente complexo

[Márcio A . Sepp]

 

Bom dia,

 

 

O que você considera um ambiente complexo? Poderia nos dar mais detalhes?

 

Na verdade eu sou apenas um entusiasta. 

Mas minha visão de ambiente complexo seria um ambiente com muitas conexões de 
acesso no banco. Tanto para alteração quanto para somente leitura e também 
tabelas com bastante registros. 

 

Como poderia ser proposto uma solução, por exemplo, para um banco como o banco 
do Brasil? (hipoteticamente é claro) com muitos acessos de leitura e também 
muitos acessos de escrita e, com um cadastro centralizado (os saldos das contas 
e os nomes dos correntistas teoricamente deveriam ser centralizados não é 
mesmo?).

 

Seguindo no exemplo hipotético do banco, de tempos em tempos teria de se fazer 
uma fragmentação das tabelas de movimento, pois senão teríamos um inchaço muito 
grande com o passar do tempo. Li sobre a herança no postgresql, alguém pode 
citar de repente alguma experiência com esse recurso? Como ficam as chaves 
estrangeiras na herança?

 

---

 

Achei interessante os links abaixo e a replicação por streaming é muito legal. 
Tenho uma dúvida em relação a ela que seria mais ou menos assim: Cliente faz 
uma operação de pagamento de um título e em seguida consulta o título 
novamente. No momento do pgto (operação de escrita), minha aplicação executa no 
servidor máster e na consulta (apenas leitura), minha aplicação consulta em um 
servidor slave. Pode ocorrer de fazer o pagamento do título e consultar em 
seguida e ainda não aparecer o pagamento? (pelo que vi pode sim, mas quanto 
tempo e onde pode ser configurado este tempo? Malefícios de deixar um time 
baixo?) 

 

 

 

Att.

Márcio A. Sepp

 

 

[1] - http://eulerto.blogspot.com.br/2010/11/replicacao-no-postgresql.html

[2] - 
http://eulerto.blogspot.com.br/2010/11/hot-standby-e-streaming-replication.html

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

[pgbr-geral] RES: Replicação horizontal de tabelas

[Márcio A . Sepp]

 

Primeiro, creio que você esteja falando de "particionamento de tabelas", e
não "replicação horizontal" (o último pode se confundir com outras
técnicas).

Correto. Perdoem meu erro...

 

Quanto à sua dúvida. Uma prática comum é que a tabela pai fique *sempre*
vazia, e coloca-se uma trigger BEFORE INSERT nesta para redirecionar as
inserções da tabela pai para as tabelas filhas.

Agora, para garantir FK, costuma-se usar um tabela shadow (sombra). Nesta
tabela vai ter apenas uma cópia da chave primária da tabela sendo
particionada (geralmente uma chave artificial int/bigint auto-incrementada),
e esta também vai ser um chave primária dessa tabela, assim sendo, sempre
que precisar de uma chave estrangeira para a tabela particionada, faz-se a
chave para esta tabela shadow. Mesmo tendo muitos registros, eles são
compostos apenas de uma coluna com um índice, logo a verificação costuma ser
rápida o suficiente.



Deixa ver se entendi:

 

Tabela pai:

CREATE TABLE movto

(

   record bigserial, 

   data date NOT NULL, 

   documento character varying(10) NOT NULL, 

  ...

  ...

   CONSTRAINT "pk-movto-record" PRIMARY KEY (record)

) ;

 

// Tabela shadow

CREATE TABLE movto_shadow

(

   record bigserial, 

   CONSTRAINT "pk-movto-record" PRIMARY KEY (record)

) ;

 

// tabelas de dados históricos

CREATE TABLE movto_hist1

(

  record bigint NOT NULL,

  data date NOT NULL DEFAULT now(),

  documento character varying(10) NOT NULL,

  CONSTRAINT "pk-movto_hist1-record" PRIMARY KEY (record),

  CONSTRAINT "fk-movto_hist1-record" FOREIGN KEY (record)

  REFERENCES movto_shadow (record) MATCH SIMPLE

  ON UPDATE CASCADE ON DELETE NO ACTION

)

 

CREATE TABLE movto_hist2

(

  record bigint NOT NULL,

  data date NOT NULL DEFAULT now(),

  documento character varying(10) NOT NULL,

  CONSTRAINT "pk-movto_hist2-record" PRIMARY KEY (record),

  CONSTRAINT "fk-movto_hist2-record" FOREIGN KEY (record)

  REFERENCES movto_shadow (record) MATCH SIMPLE

  ON UPDATE CASCADE ON DELETE NO ACTION

)

 

 

Daí monta-se uma view pra mostrar os dados pegando dos dois históricos...
não sei se entendi corretamente, mas me parece um tanto trabalhoso. 

 

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

[pgbr-geral] RES: RES: Replicação horizontal de tabelas

[Márcio A . Sepp]

[1] http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-quando/
(veja no final a sessão "Na Sequência" para um link aos demais da série)

 

Deu na veia. Obrigado!  Se ao final eu tiver dúvidas ainda reabrirei o
tópico.  

 

Muito obrigado!

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

[pgbr-geral] RES: Ordenando conforme itens na clausula in

[Márcio A . Sepp]

Select * from fabricante where id in (10,14,29,49,20)

Preciso que o select venha na mesma ordem do in, alguma ideia?


Faz assim:
Select * from fabricante where id in (10,14,29,49,20) order by id

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

[pgbr-geral] RES: RES: Ordenando conforme itens na clausula in

[Márcio A . Sepp]

Faz assim:
Select * from fabricante where id in (10,14,29,49,20) order by id

Ops, não tinha visto o 20 no final...  vai ter de usar algum outro parâmetro
para fazer isso eu acho... 

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

[pgbr-geral] RES: RES: Ordenando conforme itens na clausula in

[Márcio A . Sepp]

 

O 49 apareceria depois do 20, ou seja, não estaria na ordem dos dados internos 
do in.

 

É verdade. Achei interessante a sua solução...  

 

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

[pgbr-geral] RES: REF: INSERT tem mais expressões do que colunas alvo.

[Márcio A . Sepp]

Dá uma olhada no valor 533,57 não seria 533.57?

 

De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome
de Paulo Afonso Pereira
Enviada em: sexta-feira, 9 de janeiro de 2015 11:46
Para: pgbr-geral@listas.postgresql.org.br
Assunto: [pgbr-geral] REF: INSERT tem mais expressões do que colunas alvo.

 

Olá Pessoal,

Estou estranhando este erro. Não consegui achar o problema.

Os dados estão vindo de um XML de retorno do banco.

Não sei se é algum tipo de dado estranho, causando isso.

 

CREATE TABLE tabela_ofx

(

  idreg serial NOT NULL,

  datalan date NOT NULL,

  valorlan numeric(18,2),

  trancrdr character varying(10),

  tranidbc character varying(10),

  checknum character varying(20),

  refnum character varying(20),

  tramemo character varying(200),

  CONSTRAINT pk_idreg PRIMARY KEY (idreg )

);

 

INSERT INTO tabela_ofx 

(datalan, valorlan, trancrdr, tranidbc, checknum, refnum, tramemo) 

VALUES 

('2015-01-07', 533,57, 'CREDIT', 'N10043', '1911127', '', 'RESGATE DE
PAPEIS');

 

ERRO:  INSERT tem mais expressões do que colunas alvo

LINE 4: ...1-07', 533,57, 'CREDIT', 'N10043', '1911127', '', 'RESGATE D...

** Error **

ERRO: INSERT tem mais expressões do que colunas alvo

SQL state: 42601

Character: 159

 

ALGUMA DICA ?

 

Obrigado,

Paulo.

 

 

 

  _  


  

Este email foi escaneado pelo Avast antivírus. 
www.avast.com   

 

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

[pgbr-geral] RES: RES: RES: Replicação horizontal de tabelas

[Márcio A . Sepp]

 


[1] http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-quando/
(veja no final a sessão "Na Sequência" para um link aos demais da série)

 

Boa tarde,

 

 

Observei que, no artigo acima, o autor utiliza como chave primária campos
compostos e um dos campos (o campo que vai ser utilizado para o
particionamento), é ou integer ou character. Eu pergunto se tem algum
problema em utilizar o campo date (sem timezone) para isso?  É aconselhável?


 

No exemplo acima a tabela criada é a seguinte:

CREATE TABLE app.pedido (

ano_pedido  SMALLINT,

id_pedido   INTEGER,

data_pedido TIMESTAMP(2) NOT NULL DEFAULT now(),

...

CONSTRAINT pedido_pk PRIMARY KEY (ano_pedido, id_pedido) 

..

) WITH (autovacuum_vacuum_scale_factor=0.1,fillfactor=70)

TABLESPACE pedido; 

 

 

Quais os problemas de eu fazer simplesmente assim:

 

CREATE TABLE app.pedido (

dt_pedido  date,

id_pedido   INTEGER,

data_pedido TIMESTAMP(2) NOT NULL DEFAULT now(),

...

CONSTRAINT pedido_pk PRIMARY KEY (ano_pedido, id_pedido) 

..

) WITH (autovacuum_vacuum_scale_factor=0.1,fillfactor=70)

TABLESPACE pedido; 

 

 

 

Att.

Márcio A. Sepp

 

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

[pgbr-geral] RES: RES: RES: RES: Replicação horizontal de tabelas

[Márcio A . Sepp]

Não tem problema. É só você criar a sua CHECK CONSTRAINT de acordo. Mas veja, 
as suas cláusulas WHERE tem que bater com o que você colocar lá, senão o 
postgres vai sempre varrer todas as partições. 

 

Eu achei mais prático trabalhar com o tipo date do que em todo o SQL fazer a 
conversão (extract (year from data_pedido)) conforme sugerida no artigo para 
separar por ano. 

Só fiquei intrigado pelo fato de que o date é um tipo de dados composto e 
talvez isso poderia acarretar algum problema de performance. Vcs tem usado o 
campo date como chave da partição? 

 

 

Att.

Márcio A. Sepp

 

 

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

[pgbr-geral] RES: RES: RES: RES: RES: Replicação horizontal de tabelas

[Márcio A . Sepp]

O que você quer dizer com "date é um tipo de dados composto"?
Um campo date é um inteiro que contém o número de dias decorridos a partir
de 2000-01-01.
Ao declarar como date o PostgreSQL faz as devidas conversões.


Eu li no artigo sugerido no início desta discussão que o autor utilizava o
ano como sendo a chave e gravava como smallint no banco. Minha dúvida é se
eu, utilizando o campo date, teria a mesma performance do que utilizar um
campo inteiro?  

(se a performance é semelhante, me pergunto pq o autor deste bom material
preferiu utilizar um campo smallint ao invés de um campo date e deixando o
SQL mais complexo - pois há a necessidade de adicionar um extract na
cláusula para o planejador entender em qual fragmento da tabela ele deve
percorrer).


Att.
Márcio A. Sepp

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

[pgbr-geral] RES: Segurança dos dados

[Márcio A . Sepp]

 

Pessoal,

 

Existe alguma maneira de bloquear a visualização das functions e o seu conteúdo?

 

Quero me refereir a um bloqueio total, mesmo para os superusuários, sendo o 
acesso somente mediante a uma senha por exemplo.

 

Sei que existe meios de bloquear o acesso ao esquema por exemplo, até 
funcionaria, mas a questão é que qualquer pessoa com acesso root ao servidor 
poderia alterar o pg_hba.conf e conectar via superusuário sem utilização de 
senha, mas existe alguma forma de barrar isso, ou seria somente re-compilando o 
código fonte do postgres?

 

 

Acho que vc está falando em algo semelhante ao que o Firebird tem para 
“esconder” as triggers, procedures...  etc...  

Acho interessante...  mas não sei se o postgresql tem algo neste sentido. 

 

Att.

Márcio A. Sepp

 

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

[pgbr-geral] RES: RES: Segurança dos dados

[Márcio A . Sepp]

>
> Acho interessante...  mas não sei se o postgresql tem algo neste sentido.

Por favor, leiam as mensagens anteriores antes de responder.  Não tem, e a 
comunidade não quer que tenha, portanto não deve vir a ter.


Procuro fazê-lo sim. Posso não estar respondendo o último email da thread, pq o 
meu questionamento ou minha resposta está mais focada neste ponto e não no rumo 
que acabou tomando o assunto.

Teve um caso de desenvolvimento de sistemas comerciais onde o fisco "pegou" 
clientes utilizando o mesmo sistema, porém com comportamentos bem distintos. 
Neste caso específico, a pessoa que foi implantar o sistema alterou funções do 
sistema de modo a permitir um "caixa 2". Este sistema era desenvolvido em 
Firebird e depois desse fato, a empresa desenvolvedora optou por ocultar o 
código fonte dos procedimentos do banco...  

Pelo que vi Oracle implementa algo neste sentido tbm. Mas não sei se é um 
anseio de outros usuários isso ou se eu estou divagando...  

Observe que eu não estou me referindo a ocultar o código fonte de 
procedures/functions/triggers... e não em "fechar" o código fonte do 
postgresql. 

Att.
Márcio A. Sepp

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

[pgbr-geral] RES: RES: RES: Segurança dos dados

[Márcio A . Sepp]

Correções... 

Onde está escrito: "... funções do sistema..."  eu quis dizer funções do
banco.

Onde está escrito: "... Observe que eu NÃO estou me referindo a ocultar o
código fonte de procedures/functions/triggers... "  tire o "NÃO"

Por favor, desculpem...  




Segue texto correto:

Procuro fazê-lo sim. Posso não estar respondendo o último email da thread,
pq o meu questionamento ou minha resposta está mais focada neste ponto e não
no rumo que acabou tomando o assunto.

Teve um caso de desenvolvimento de sistemas comerciais onde o fisco "pegou"
clientes utilizando o mesmo sistema, porém com comportamentos bem distintos.
Neste caso específico, a pessoa que foi implantar o sistema alterou funções
do BANCO de modo a permitir um "caixa 2". Este sistema era desenvolvido em
Firebird e depois desse fato, a empresa desenvolvedora optou por ocultar o
código fonte dos procedimentos do banco...  

Pelo que vi Oracle implementa algo neste sentido tbm. Mas não sei se é um
anseio de outros usuários isso ou se eu estou divagando...  

Observe que eu estou me referindo a ocultar o código fonte de
procedures/functions/triggers... e não em "fechar" o código fonte do
postgresql. 



Att.
Márcio A. Sepp


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

[pgbr-geral] RES: RES: RES: Segurança dos dados

[Márcio A . Sepp]

... uma opção que não informaram é que se as suas funções foram feitas em C,
você pode "esconder" o código fonte.


Creio que isso resolve. 


No seu caso, o ideal é proteger por contrato qualquer mudança no seu produto
(como já foi dito pelo Dutra). Talvez algum módulo de auditoria em C para
lhe proteger contra mudanças que visam burlar o seu sistema.


O ideal seria, mas aqui a banda toca em sustenido! Quero dizer que, se for
pra justiça, vc tem uma série de outros problemas e demoa  a
empresa em questão teve a venda suspensa de seus produtos em alguns estados
por conta disso e até provar que não foi ela que vez, a solução acabou sendo
a ofuscação do código mesmo.



[1] https://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want


Não sabia disso...  mas a solução em C já atende.


Obrigado.

Márcio A. Sepp
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] RES: RES: RES: Segurança dos dados

[Márcio A . Sepp]

 

Não seria mais fácil embutir essa função no código do sistema ao invés de
fazer em PL? Assim a preocupação com segurança de código fica só no lado da
aplicação e menos no banco de dados.

 

Concordo. Mas não o fizeram assim...  provavelmente por causa do desempenho,
mas creio que se fossem fazer hoje novamente iriam rever essa questão.

 

 

Por outro lado, se a empresa do colega é tem tanta preocupação assim com a
segurança da linguagem procedural, o mesmo se aplica para seus dados.

 

Em resumo, os dedões que não deveria alterar PL também não deveriam poder
alterar dados sem passar pela aplicação.

 

Logo, o problema de segurança me parece mais embaixo...

 

 

Concordo. Pouco adianta bloquear o acesso as funções/procedures e deixar a
base de dados aberta pra acesso... 

 

 

Obrigado! A função em C atende.

 

 

Márcio A. Sepp 

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

[pgbr-geral] RES: SELECT FOR UPDATE tentando obter lock

[Márcio A . Sepp]

--1.a tabela 
create table pessoa(
codp integer primary key,
nome varchar(10)
);

--2.a tabela 
create table animal( 
coda integer primary key,
raca varchar(10),
codp integer references pessoa(codp)
);


-- inserção de dados 
insert into pessoa values (1, 'rosa');
insert into pessoa values (2, 'maria');
insert into pessoa values (3, 'josé');



 -- transacao - TA

begin;
insert into animal values (108, 'viralata', 1); 
select * from animal;
select * from pessoa;


--transacao  -TB

begin;
update pessoa set nome = 'rosana' where nome = 'rosa';     -- executado com
sucesso
update pessoa set nome = 'rosa de' where codp=1;  -- executado com sucesso
select nome from pessoa  for update nowait;   -- erro! 


** Error **

ERROR: could not obtain lock on row in relation "pessoa"
SQL state: 55P03



Testei o script exatamente como vc postou aqui, mas não obtive este lock.
Minha versão do postgres é 9.3.2. 

Na versão 9.0 o comando:
update pessoa set nome = 'rosana' where nome = 'rosa'; 

fica aguardando a transação anterior. 
 


Att.
Márcio A. Sepp

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

[pgbr-geral] Ajuda com trigger

[Márcio A . Sepp]

Preciso criar uma trigger em uma tabela que faça inserts/updates nela mesma.

Como faço para resolver o problema do loop?  


Att.
Márcio A. Sepp

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

[pgbr-geral] RES: SELECT FOR UPDATE tentando obter lock

[Márcio A . Sepp]

> 2. Só de curiosidade, fizemos o mesmo teste no Oracle e não ocorreu 
> erro algum.
>E agora?
>Quem poderá nos defender??   rss
> 
Muito estranho ele não falhar (no caso do NOWAIT) ou ficar esperando (sem
NOWAIT) pois isso pode acarretar perda de integridade. O que acontece se na
transação B você alterar o codp de 1 para 2?


Talvez tenha a ver com o fato de o Oracle não possibilitar (ao menos até a
10G) update cascade na chave. 

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

[pgbr-geral] RES: Estrutura do Postgres orientado a objetos

[Márcio A . Sepp]

Em 28 de abril de 2015 20:29, Matheus Saraiva  
escreveu:
> Pois é, vejo que, em parte, eu meio que entendia errado essa "critica" 
> às chaves artificiais.
> Hoje mesmo quando enviei a primeira pergunta eu me referia ao uso de 
> chaves naturais compostas em relacionamentos, ou seja, como chaves primárias.

Sim, seria o ideal, pelo menos na ausência de separação de modelos lógico e 
físico.


> Eu me
> refira justamente a uma modelagem sem chaves artificiais, onde os 
> campos que compunham as chaves primárias são replicados nas outras tabelas.

E é o que eu dizia que geralmente não é problema algum.


> Esse tipo de modelagem acredito ser complicado em requisitos de 
> hardware limitados principalmente por alguma restrição de armazenamento.

É essa crença que se constitui em (falsa) otimização precoce, que como todos 
sabemos é raiz de toda sorte de males.



Deixa ver se entendi direito. Vou criar abaixo uma sequencia de tabelas 
utilizando chaves naturais e farei a ligação das tabelas de cadastro com uma 
tabela de pedido por exemplo.

CREATE TABLE public.pais
(
   codigo integer, 
   nome character varying(50) NOT NULL, 
   PRIMARY KEY (codigo)
);
// o código do país é obtido em catálogos internacionais de países (acho que o 
FEBRABAN o outro órgão disponibiliza). Então é um código associado a estas 
lista.


CREATE TABLE public.uf
(
   codpais integer NOT NULL, 
   coduf integer NOT NULL, 
   sigla character(2) NOT NULL, 
   descricao character varying(50) NOT NULL, 
   PRIMARY KEY (codpais, coduf), 
   FOREIGN KEY (codpais) REFERENCES pais (codigo) ON UPDATE CASCADE ON DELETE 
NO ACTION
);

// O código da UF tbm é fornecido por algum órgão, no caso o IBGE. O mesmo 
ocorre com o código da cidade abaixo.

CREATE TABLE cidade
(
  codpais integer NOT NULL,
  coduf integer NOT NULL,
  codcidade integer NOT NULL,
  nome character varying(50) NOT NULL,
  CONSTRAINT cidade_pkey PRIMARY KEY (codpais, coduf, codcidade),
  CONSTRAINT cidade_codpais_fkey FOREIGN KEY (codpais, coduf)
  REFERENCES uf (codpais, coduf) MATCH SIMPLE
  ON UPDATE CASCADE ON DELETE NO ACTION
);


CREATE TABLE public.bairro
(
   codpais integer NOT NULL, 
   coduf integer NOT NULL, 
   codcidade integer NOT NULL, 
   bairro character varying(50) NOT NULL, 
   PRIMARY KEY (codpais, coduf, codcidade, bairro), 
   FOREIGN KEY (codpais, coduf, codcidade) REFERENCES cidade (codpais, coduf, 
codcidade) ON UPDATE CASCADE ON DELETE NO ACTION
);

CREATE TABLE public.rua
(
   codpais integer NOT NULL, 
   coduf integer NOT NULL, 
   codcidade integer NOT NULL, 
   bairro character varying(50) NOT NULL, 
   rua character varying(50) NOT NULL, 
   PRIMARY KEY (codpais, coduf, codcidade, bairro, rua), 
   FOREIGN KEY (codpais, coduf, codcidade, bairro) REFERENCES bairro (codpais, 
coduf, codcidade, bairro) ON UPDATE CASCADE ON DELETE NO ACTION
);


CREATE TABLE public.pedido
(
   codpedido serial NOT NULL, 
   codpais integer NOT NULL, 
   coduf integer NOT NULL, 
   codcidade integer NOT NULL, 
   bairro character varying(50) NOT NULL, 
   rua character varying(50) NOT NULL, 
   numero integer, 
   PRIMARY KEY (codpedido), 
   FOREIGN KEY (codpais, coduf, codcidade, bairro, rua) REFERENCES rua 
(codpais, coduf, codcidade, bairro, rua) ON UPDATE CASCADE ON DELETE NO ACTION
);

Se esta tabela de pedido tiver, digamos que 10.000 pedidos/dia. Qual o inchaço 
que irá representar criando-a desta forma? Não seria menos custoso criar uma 
chave artificial na tabela "rua" para ligar com a tabela de pedido?

Em contrapartida, digamos que é imprescindível que o banco de dados forneça a 
informação de quanto foi feito de pedido por rua, bairro, cidade, uf e país. 



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

[pgbr-geral] Como pegar os comentários

[Márcio A . Sepp]

 

Bom dia,

 

 

Preciso pegar os comentários das tabelas, dos campos, constraints...  onde
eu consigo encontrar no catálogo estas informações?

 

 

Att.

Márcio A. Sepp

 

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

[pgbr-geral] RES: Como pegar os comentários

[Márcio A . Sepp]

Muito obrigado Matheus e Douglas. 
Suas colocações Matheus eram exatamente o que eu estava procurando.


Att.
Márcio A. Sepp

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

[pgbr-geral] Postgres conversando com firebird

[Márcio A . Sepp]

Boa tarde,


Gostaria de saber se alguém da lista conhece ou se existe alguma maneira
nativa de um servidor postgresql conversar com um banco de dados firebird?


Att.
Márcio A. Sepp



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

[pgbr-geral] Procedure dentro de outra procedure

[Márcio A . Sepp]

Boa tarde,


Gostaria de saber se tem como colocar uma procedure dentro de outra para
chamá-la apenas de dentro da procedure “mãe”. 

Exemplo:
CREATE OR REPLACE FUNCTION fmae() RETURNS trigger AS
$BODY$
  DECLARE
PROCEDURE DOINSERT(INTEGER);
BEGIN
  -- COMANDOS... 
END;
begin
  DOINSERT(INTEGER);
-- COMANDOS;
  DOINSERT(INTEGER);
END;
  

Att.
Márcio A. Sepp

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

[pgbr-geral] RES: Procedure dentro de outra procedure

[Márcio A . Sepp]

Não entendi muito bem o que vc quer fazer...

Tenho uma função que é relativamente grande e no seu "desenrolar" invoca 
diversas vezes um comando de insert/update em outra tabela. Então pra minha 
comodidade, criei uma função para executar este insert/update. Até aí tudo bem, 
mas como este insert/update é apenas executado de dentro desta função, acho 
meio "exagerado" deixá-lo aparecendo lá nas functions do postgres e até acaba 
sendo feio ver este código que é apenas usado dentro de uma trigger 
especificamente.
Só por questão de organização mesmo.



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

[pgbr-geral] RES: Procedure dentro de outra procedure

[Márcio A . Sepp]

Boa tarde,


Gostaria de saber se tem como colocar uma procedure dentro de outra para
chamá-la apenas de dentro da procedure “mãe”.

Basicamente, não.

Se entendi bem, você precisar criar uma função para chama-la, veja:

CREATE FUNCTION f_insert(int) RETURNS int AS $$
BEGIN
-- do the insert
END;
$$ LANGUAGE plpgsql;

CREATE FUNCTION f_delete(int) RETURNS int AS $$
BEGIN
-- do the delete
END;
$$ LANGUAGE plpgsql;

CREATE FUNCTION f_tudo_junto(int) RETURNS void AS $$
BEGIN
PERFORM f_insert($1);
PERFORM f_delete($1);
END;
$$ LANGUAGE plpgsql;



Ok. Entendi Sebastian. Muito obrigado!

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

[pgbr-geral] RES: RES: Procedure dentro de outra procedure

[Márcio A . Sepp]

CREATE OR REPLACE FUNCTION ..
AS
$$
DECLARE
 ins_cmd text;

BEGIN
ins_cmd = 'INSERT INTO tabela(coluna1, coluna2) values ($1, $2)';

   < comandos da funcao aqui>

EXECUTE ins_cmd using var1, var2;

   < comandos da funcao aqui>

EXECUTE ins_cmd using varN, varM;

   < comandos da funcao aqui>

END;
$$ LANGUAGE PLPGSQL;


Acho que resolve pra mim...  muito obrigado!

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

[pgbr-geral] Quantidade de campos na chave primária

[Márcio A . Sepp]

Boa tarde,


Estou modelando uma base de dados onde em alguns casos eu tenho até 12
campos na chave primária. 
Estas tabelas ficam na borda da modelagem, ou seja, são tabelas de
movimentação as quais recebem um número maior de registros.
Gostaria da opinião dos colegas se isso pode significar algum problema pra
mim no futuro. (desempenho, espaço... etc). 

A título de informação, em torno de 40% destes campos são smallint, 40% são
integer, 10% char(1) e 10% bigint.


Att.
Márcio A. Sepp


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

[pgbr-geral] RES: Quantidade de campos na chave primária

[Márcio A . Sepp]

Acho que ficou um pouco confusa minha explicação, ou deu para o gasto?


Deu pro gasto!  Rsss Muito obrigado!

Só pra te falar, minhas tabelas são +/- assim:
Tabela1
 * pk_tab1

Tabela2
 * pk_tab1
 * pk_tab2

Tabela3
 * pk_tab1
 * pk_tab2
 * pk_tab3
...

Tabela6
 * pk_tab1
 ...
 ...
 * pk_tab12

Na prática...  lá pelo 6 nível, eu tenho uma tabela com 12 campos na chave. 
Todos os relacionamentos estão em cascade. O que me assustou é a quantidade de 
campos na chave primária e os impactos disso no banco de dados... Acaso tens 
alguma medição do desempenho de um banco escrito desta forma? 

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

[pgbr-geral] Problemas de desempenho

[Márcio A . Sepp]

Bom dia,


Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7 e após
atualização esta query passou a ficar extremamente lenta.

SQL:
select movto_lote.nr_dcto
from fin_receber_parc parc 
inner join fin_receber receber on (receber.cd_movto = parc.cd_movto_rec and 
   receber.cd_serie_lcto =
parc.cd_serie_lcto) 
inner join fin_receber_cnt cnt on (cnt.cd_movto_rec= receber.cd_movto and 
   cnt.cd_serie_lcto=receber.cd_serie_lcto) 
inner join cnt_movto movto on (cnt.cd_movto=movto.cd_movto and 
   movto.cd_serie_lcto=cnt.cd_serie_lcto) 
inner join cnt_movto_lote movto_lote on (movto_lote.cd_movto =
movto.cd_movto_lote and 
 movto_lote.cd_serie_lcto =
movto.cd_serie_lcto) 
inner join cnt_competencia competencia on (competencia.cd_competencia =
movto_lote.cd_competencia) 
inner join uni_emitente emitente on (emitente.cd_emitente =
receber.cd_devedor) 
inner join fin_especie especie on (especie.cd_especie = parc.cd_especie ) 
where upper(coalesce(movto_lote.ds_historico, '%')) like upper('%%') and 
  upper(coalesce(movto_lote.nr_dcto, '%')) like upper('%%') and 
  upper(coalesce(competencia.nm_competencia, '%')) like upper('%%') and 
  upper(coalesce(emitente.nm_emitentecompleto, '%')) like
upper('%consumidor%') and 
  coalesce(parc.vl_valor, 0) between coalesce(0, 0) and
coalesce(99.99, 9) and 
  coalesce(receber.cd_devedor, 0) between coalesce(0, 0) and
coalesce(9, 9) and 
  movto_lote.dt_movto between ('01/01/2000') and ('01/03/') and 
  parc.dt_vcto between ('01/01/2000') and ('31/12/') and 
  parc.st_quitado = false and 
  movto_lote.cd_estabelecimento=1 
order by parc.dt_vcto desc


Saída do Explain Analyze:
"Sort  (cost=4779.91..4779.91 rows=1 width=16) (actual
time=128286.342..128286.342 rows=6 loops=1)"
"  Sort Key: parc.dt_vcto DESC"
"  Sort Method: quicksort  Memory: 25kB"
"  ->  Nested Loop  (cost=1.96..4779.90 rows=1 width=16) (actual
time=126064.707..128286.279 rows=6 loops=1)"
"Join Filter: (parc.cd_especie = especie.cd_especie)"
"Rows Removed by Join Filter: 36"
"->  Nested Loop  (cost=1.96..4778.74 rows=1 width=18) (actual
time=126064.672..128286.198 rows=6 loops=1)"
"  ->  Nested Loop  (cost=1.68..4777.55 rows=1 width=22) (actual
time=64031.477..128247.981 rows=3189 loops=1)"
"Join Filter: (movto_lote.cd_competencia =
competencia.cd_competencia)"
"Rows Removed by Join Filter: 15945"
"->  Nested Loop  (cost=1.68..4776.37 rows=1 width=26)
(actual time=64031.432..128164.285 rows=3189 loops=1)"
"  Join Filter: (receber.cd_serie_lcto =
movto_lote.cd_serie_lcto)"
"  ->  Nested Loop  (cost=1.26..4775.86 rows=1
width=26) (actual time=0.085..128005.877 rows=6277 loops=1)"
"Join Filter: (receber.cd_serie_lcto =
movto.cd_serie_lcto)"
"->  Nested Loop  (cost=0.83..4774.95 rows=1
width=24) (actual time=0.078..127775.182 rows=6277 loops=1)"
"  ->  Nested Loop  (cost=0.42..3012.16
rows=1 width=30) (actual time=0.067..214.384 rows=6318 loops=1)"
"->  Seq Scan on
fin_receber_parc parc  (cost=0.00..2745.68 rows=32 width=16) (actual
time=0.052..91.802 rows=6318 loops=1)"
"  Filter: ((NOT st_quitado)
AND (COALESCE(vl_valor, '0'::numeric) >= '0'::numeric) AND
(COALESCE(vl_valor, '0'::numeric) <= 99.99) AND (dt_vcto >=
'2000-01-01'::date) AND (dt_vcto <= '-12-31'::date))"
"  Rows Removed by Filter:
81216"
"->  Index Scan using
"pk-fin_receber-geral" on fin_receber receber  (cost=0.42..8.32 rows=1
width=14) (actual time=0.013..0.014 rows=1 loops=6318)"
"  Index Cond: ((cd_movto =
parc.cd_movto_rec) AND (cd_serie_lcto = parc.cd_serie_lcto))"
"  Filter:
((COALESCE(cd_devedor, 0) >= 0) AND (COALESCE(cd_devedor, 0) <= 9))"
"  ->  Index Scan using
"pk-fin_receber_cnt-cd_movto-cd_serie_lcto" on fin_receber_cnt cnt
(cost=0.42..1762.78 rows=1 width=18) (actual time=7.918..20.187 rows=1
loops=6318)"
"Index Cond: (cd_serie_lcto =
receber.cd_serie_lcto)"
"Filter: (receber.cd_movto =
cd_movto_rec)"
"Rows Removed by Filter: 87707"
"->  Index Scan using
"pk-cnt_movto-cd_movto-cd_serie_lcto" on cnt_movto movto  (cost=0.42..0.90
rows=1 width=18) (actual time=0.031..0.031 rows=1 loops=6277

[pgbr-geral] RES: Problemas de desempenho

[Márcio A . Sepp]

> Bom dia,
>
>
> Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7 
> e após atualização esta query passou a ficar extremamente lenta.
>
> SQL:
> select movto_lote.nr_dcto
> from fin_receber_parc parc
> inner join fin_receber receber on (receber.cd_movto = parc.cd_movto_rec and
>receber.cd_serie_lcto =
> parc.cd_serie_lcto)
> inner join fin_receber_cnt cnt on (cnt.cd_movto_rec= receber.cd_movto and
>
> cnt.cd_serie_lcto=receber.cd_serie_lcto)
> inner join cnt_movto movto on (cnt.cd_movto=movto.cd_movto and
>movto.cd_serie_lcto=cnt.cd_serie_lcto)
> inner join cnt_movto_lote movto_lote on (movto_lote.cd_movto = 
> movto.cd_movto_lote and
>  movto_lote.cd_serie_lcto =
> movto.cd_serie_lcto)
> inner join cnt_competencia competencia on (competencia.cd_competencia 
> =
> movto_lote.cd_competencia)
> inner join uni_emitente emitente on (emitente.cd_emitente =
> receber.cd_devedor)
> inner join fin_especie especie on (especie.cd_especie = 
> parc.cd_especie ) where upper(coalesce(movto_lote.ds_historico, '%')) like 
> upper('%%') and
>   upper(coalesce(movto_lote.nr_dcto, '%')) like upper('%%') and
>   upper(coalesce(competencia.nm_competencia, '%')) like upper('%%') and
>   upper(coalesce(emitente.nm_emitentecompleto, '%')) like
> upper('%consumidor%') and
>   coalesce(parc.vl_valor, 0) between coalesce(0, 0) and 
> coalesce(99.99, 9) and
>   coalesce(receber.cd_devedor, 0) between coalesce(0, 0) and 
> coalesce(9, 9) and
>   movto_lote.dt_movto between ('01/01/2000') and ('01/03/') and
>   parc.dt_vcto between ('01/01/2000') and ('31/12/') and
>   parc.st_quitado = false and
>   movto_lote.cd_estabelecimento=1
> order by parc.dt_vcto desc
>
>
> Saída do Explain Analyze:
> "Sort  (cost=4779.91..4779.91 rows=1 width=16) (actual
> time=128286.342..128286.342 rows=6 loops=1)"
> "  Sort Key: parc.dt_vcto DESC"
> "  Sort Method: quicksort  Memory: 25kB"
> "  ->  Nested Loop  (cost=1.96..4779.90 rows=1 width=16) (actual
> time=126064.707..128286.279 rows=6 loops=1)"
> "Join Filter: (parc.cd_especie = especie.cd_especie)"
> "Rows Removed by Join Filter: 36"
> "->  Nested Loop  (cost=1.96..4778.74 rows=1 width=18) (actual
> time=126064.672..128286.198 rows=6 loops=1)"
> "  ->  Nested Loop  (cost=1.68..4777.55 rows=1 width=22) (actual
> time=64031.477..128247.981 rows=3189 loops=1)"
> "Join Filter: (movto_lote.cd_competencia =
> competencia.cd_competencia)"
> "Rows Removed by Join Filter: 15945"
> "->  Nested Loop  (cost=1.68..4776.37 rows=1 width=26)
> (actual time=64031.432..128164.285 rows=3189 loops=1)"
> "  Join Filter: (receber.cd_serie_lcto =
> movto_lote.cd_serie_lcto)"
> "  ->  Nested Loop  (cost=1.26..4775.86 rows=1
> width=26) (actual time=0.085..128005.877 rows=6277 loops=1)"
> "Join Filter: (receber.cd_serie_lcto =
> movto.cd_serie_lcto)"
> "->  Nested Loop  (cost=0.83..4774.95 rows=1
> width=24) (actual time=0.078..127775.182 rows=6277 loops=1)"
> "  ->  Nested Loop  (cost=0.42..3012.16
> rows=1 width=30) (actual time=0.067..214.384 rows=6318 loops=1)"
> "->  Seq Scan on
> fin_receber_parc parc  (cost=0.00..2745.68 rows=32 width=16) (actual
> time=0.052..91.802 rows=6318 loops=1)"
> "  Filter: ((NOT st_quitado)
> AND (COALESCE(vl_valor, '0'::numeric) >= '0'::numeric) AND 
> (COALESCE(vl_valor, '0'::numeric) <= 99.99) AND (dt_vcto >=
> '2000-01-01'::date) AND (dt_vcto <= '-12-31'::date))"
> "  Rows Removed by Filter:
> 81216"
> "->  Index Scan using
> "pk-fin_receber-geral" on fin_receber receber  (cost=0.42..8.32 rows=1
> width=14) (actual time=0.013..0.014 rows=1 loops=6318)"
> "  Index Cond: ((cd_movto =
> parc.cd_movto_rec) AND (cd_serie_lcto = parc.cd_serie_lcto))"
> "  Filter:
> ((COALESCE(cd_devedor, 0) >= 0) AND (COALESCE(cd_devedor, 0) <= 9))"
> "  ->  Index Scan using
> "pk-fin_receber_cnt-cd_movto-cd_serie_lcto" on fin_receber_cnt cnt
> (cost=0.42..1762.78 rows=1 width=18) (actual time=7.918..20.187 rows=1 
> loops=6318)"
> "Index Cond: (cd_serie_lcto =
> receber.cd_serie_lcto)"
> "Filter: (receber.cd_movto =
> cd_movto_rec)"
> "Rows Removed by Filter: 87707"
> "  

[pgbr-geral] RES: RES: Problemas de desempenho

[Márcio A . Sepp]

 

2016-04-04 17:47 GMT-03:00 Márcio A. Sepp :

> Bom dia,
>
>
> Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7
> e após atualização esta query passou a ficar extremamente lenta.
>.
>
>
> Pelo que estou entendendo o problema está no fin_receber_cnt. Mas não
> to achando o furo.
> Observem que na versão 9.0 estava funcionando de forma satisfatoria.
>


Atualize as estatísticas com o comando ANALYZE.
http://www.postgresql.org/docs/9.4/interactive/sql-analyze.html



Por favor, me explique como vc chegou a esta conclusão? diz algo aí que as 
estatísticas estão desatualizadas? (eu não manjo muito da saída do analyze e to 
me batendo nisso a horas).
Mas eu havia feito todas as manutenções antes de enviar a saída do analyze e 
inclusive peguei o banco e subi numa máquina minha e continua na mesma lentidão.

Talvez precise que eu envie mais alguma informação pra ajudar?

 

O tempo estimado e o tempo real são muito divergentes, talvez por isso a 
sugestão do analyze, e também porque é praxe que as estatísticas estejam 
desatualizadas.

Utilize [1] para facilitar a visualização, se possível, e cole a URL do seu 
explain.

O problema parece começar em alguns loops e filtros sem índices, mas será 
melhor de visualizar após nos passar o link do explain.

Eu tentei utilizando o resultado que você passou e não deu certo.

 

[1] - http://explain.depesz.com/ 

 

Rodei analyze (no banco que subi aqui) agora. 

 

 

http://explain.depesz.com/s/b55L

 

 

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

[pgbr-geral] RES: RES: RES: Problemas de desempenho

[Márcio A . Sepp]

 

2016-04-04 17:47 GMT-03:00 Márcio A. Sepp :

> Bom dia,
>
>
> Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7
> e após atualização esta query passou a ficar extremamente lenta.
>.
>
>
> Pelo que estou entendendo o problema está no fin_receber_cnt. Mas não
> to achando o furo.
> Observem que na versão 9.0 estava funcionando de forma satisfatoria.
>


Atualize as estatísticas com o comando ANALYZE.
http://www.postgresql.org/docs/9.4/interactive/sql-analyze.html

Por favor, me explique como vc chegou a esta conclusão? diz algo aí que as 
estatísticas estão desatualizadas? (eu não manjo muito da saída do analyze e to 
me batendo nisso a horas).
Mas eu havia feito todas as manutenções antes de enviar a saída do analyze e 
inclusive peguei o banco e subi numa máquina minha e continua na mesma lentidão.

Talvez precise que eu envie mais alguma informação pra ajudar?

 

O tempo estimado e o tempo real são muito divergentes, talvez por isso a 
sugestão do analyze, e também porque é praxe que as estatísticas estejam 
desatualizadas.

Utilize [1] para facilitar a visualização, se possível, e cole a URL do seu 
explain.

O problema parece começar em alguns loops e filtros sem índices, mas será 
melhor de visualizar após nos passar o link do explain.

Eu tentei utilizando o resultado que você passou e não deu certo.

 

[1] - http://explain.depesz.com/ 

 

Rodei analyze (no banco que subi aqui) agora. 

 

 

http://explain.depesz.com/s/b55L

 

 

 

Fazendo testes, percebi que o problema está nestas duas linhas aqui:

  upper(coalesce(emitente.nm_emitentecompleto, '%')) like 
upper('%consumidor%') and 

  coalesce(parc.vl_valor, 0) between coalesce(0, 0) and coalesce(99.99, 
9) and

 

Comentando elas o retorno fica em 2 ms, o que é aceitável.

Tentei retirar os operadores upper e coalesce destas linhas, mas ainda continua 
lento. Fui até as tabelas emitente e parc e criei indices nestas colunas, mas 
tbm não resolveu. Se alguém puder ajudar, agradeço muito.

 

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

[pgbr-geral] RES: RES: RES: RES: Problemas de desempenho

[Márcio A . Sepp]

 

Márcio, realmente, o upper e o coalesce impedem o uso do índice no campo. 
Sugiro você criar um índice com o campo já maiúsculo e remover o coalesce, já 
que me parece não ter muito uso substituir os nulos por '%' (provavelmente essa 
cláusula não tem efeito algum na sua consulta, a menos que ela seja gerada 
dinamicamente). Faça o mesmo para os demais campos e rode um analyze novamente, 
só para garantir. :)

 

CREATE INDEX ON emitente ((upper(nm_emitentecompleto)));

 

Para resolver a cláusula em parc.vlr_valor, sugiro você isolar os valores nulos 
em uma condição própria, algo como:

 

(parc.vl_valor between 0 and 9 or parc.vl_valor is null)

 

 

No parc.vl_valor eu setei para not null e, tirando o coalesce ficou muito bom.

Agora criei o índice na tabela uni_emitente (cfe o comando que vc passou 
acima), rodei analyze no banco todo, deixei a linha assim: 
emitente.nm_emitentecompleto like '%CONSUMIDOR%' and

e não resolveu. Se comento esta linha fica bala.

Pra ter uma idéia tá rodando a 20 minutos e não vai. Não consigo nem tirar o 
analyze pra enviar.

 

 

Agora, apenas para entendimento:

1) Onde diz no explain analyze que o problema era com estas duas linhas? (como 
disse, sou bem leigo nisso e to tentando aprender - Talvez nem tem como saber 
por ele...);

 

2) Sabem o pq dele rodar bem na 9.0 e lento na 9.4 e 9.5? 

Passei por alto no relnotes, mas não encontrei nada... (talvez tenha visto, mas 
como não manjo muito, posso não ter entendido)

 

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

[pgbr-geral] RES: Binary column - Setando null

[Márcio A . Sepp]

Sim, você precisa fazer um vacuum full da tabela ou um dump/restore, ou 
recriá-la de outra forma como criando uma nova tabela temporária, apaga a 
antiga e renomeia a nova.

Aliás, eu não faria seu update porque ele possívelmente vai tomar um tempo 
enorme - eu criaria uma nova tabela só com as colunas que interessam e depois 
apagaria a antiga.


Dropar o campo e depois recriá-lo (para as aplicações que fazem referencia não 
darem problema)?!?!? 


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

[pgbr-geral] RES: Consulta a código NCM

[Márcio A . Sepp]

 

Pessoal,

 

Gostaria de compartilhar um problema e verificar se alguém pode me dar uma 
opinião.

 

Tenho a necessidade de associar características a um NCM 

 . Um código NCM é formado da seguinte forma:

 

SEÇÃO   I DEFINIÇÃO

Capítulo  01   Animais vivos

Posição   0104Animais vivos das espécies 
ovinas ou caprinas

Subposição 0104.10  Ovinos

Item0104.10.1   Reprodutores de raça pura

Subitem  0104.10.11  Prenhe ou com cria ao pé

 

 

Acontece que a característica pode estar associado a qualquer nível do NCM. O 
fato é que quando eu fizer uma consulta a um código 0104.10.11, tenho que 
retornar as características que estão associadas diretamente ao código e também 
as características que estiverem associadas aos códigos de hierarquias 
superiores.

 

Minha dúvida está em qual seria a melhor forma de armazenar este código, para 
que as consultas tenham a melhor performance.

 

Armazenar cada pedaço do código em uma coluna separada, ou gravar em um único 
campo string?

 

Existe alguma forma melhor de executar a consulta (performance) do que a 
abaixo? 

 

select * from ncmcaracteristica

Where

subitem = '0104.10.11'

OR item = '0104.10.1'

OR subposicao = '0104.10'

OR posicao = '0104'

OR capitulo = '01'

 

 

Dê uma olhada na cláusula with recursive. Dependendo como está a sua estrutura, 
pode ser aplicado no seu caso.

http://www.postgresql.org/docs/9.5/static/queries-with.html

 

 

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

[pgbr-geral] Constraints x bloqueios

[Márcio A . Sepp]

 

Bom dia,

 

 

Gostaria de saber a relação que existe entre FKs e bloqueios de registros.
Por exemplo, se eu criar uma FK com os parâmetros: ON UPDATE NO ACTION  /
ON DELETE NO ACTION isso vai dar alguma diferença nos bloqueios da tabela
mestre? 

 

 

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

[pgbr-geral] RES: Constraints x bloqueios

[Márcio A . Sepp]

On 20-05-2016 12:06, Márcio A. Sepp wrote:
> Gostaria de saber a relação que existe entre FKs e bloqueios de 
> registros. Por exemplo, se eu criar uma FK com os parâmetros: ON 
> UPDATE NO ACTION  /  ON DELETE NO ACTION isso vai dar alguma diferença 
> nos bloqueios da tabela mestre?
> 
A partir da 9.3, atualizações em campos que não fazem parte da chave
*não* bloqueiam verificações de chaves estrangeiras. Tal funcionalidade criou 
novos modos de bloqueio [1] a nível de registros: FOR NO KEY UPDATE e FOR KEY 
SHARE.


[1]
http://www.postgresql.org/docs/9.6/static/explicit-locking.html#LOCKING-ROWS


Obrigado Euler, era exatamente isso que eu estava precisando.


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

[pgbr-geral] RES: Chave Primaria Composta

[Márcio A . Sepp]

Depende, lá como eu disse as chaves compostas foram usadas de forma errada, era 
uma estrutura de grupo, empresa, filial, unidade + chave_negocio_tabela, então 
de cara qualquer PK já tinha no mínimo 5 campos!
Sem contas outras gambiarras que não vem ao caso aqui.



Boa tarde,

Vou dar uma pitada aqui, embora não sou bem um conhecedor da área. A meu ver, 
justamente vc colocando mais atributos na chave primária deveria deixar as 
consultas mais rápidas (se vc utilizar os campos da chave no where) e, como 
consequencia, talvez iria utilizar mais o disco para 
armazenamento (falando a grosso modo).

Este assunto eu já havia levantado aqui na lista um tempo atrás e eu tbm tenho 
dúvidas em relação a quantidade de campos na chave. Justamente nesta parte mais 
baixa da contabilidade eu cheguei a 9 campos na chave da tabela de movimentação 
por projeto. Tbm achei estranho isso, pois nunca havia visto uma chave primária 
tão grande...  

No meu caso a chave está assim:
  character varying(10)
  bigint 
  smallint 
  smallint 
  smallint 
  integer 
  character(1)
  integer 
  integer 

Não coloquei os nomes dos campos pq eles seguem um propósito próprio e teria de 
colocar uma legenda pra eles e não é o propósito.

Por favor, comentem. 


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

[pgbr-geral] RES: RES: Chave Primaria Composta

[Márcio A . Sepp]

> Márcio, quando for citar algo que alguém mais escreveu, marque para
> evitar confusão.

Desculpe, consegui acertar agora meu leitor de emails pra isso...  tempo já que 
tava procurando. 

> 
> > Vou dar uma pitada aqui, embora não sou bem um conhecedor da área. A
> > meu ver, justamente vc colocando mais atributos na chave primária
> deveria deixar as consultas mais rápidas (se vc utilizar os campos da
> chave no where) e, como consequencia, talvez iria utilizar mais o disco
> para armazenamento (falando a grosso modo).
> 
> Não.
> 
> Os atributos de uma chave por definição já existem no disco.  A rigor,
> é a chave artificial, apesar de poder ser simples, que representa
> desperdício, visto que tem de ser definida (incluindo índice) além das
> chaves naturais (nunca as substituindo!), sejam estas compostas ou
> simples.
> 
> A eventual economia de armazenamento seria para o caso de tabelas
> ‘pai’, que ‘exportariam’ apenas um atributo para as ‘filhas’.  Mas essa
> economia geralmente é mais que contrabalançada por haver índice e
> atributo adicional nas tabelas pais, e pelo fato de que chaves
> artificiais quase sempre exigem mais junções, visto que as chaves
> estrangeiras nas tabelas filhas não contém informações úteis; e pelo
> fato de que geralmente as pessoas acabam não definindo chaves naturais
> quando definem as artificiais, o que gera, além de inconsistências,
> necessidade de tratar integridade na aplicação, o que é muito
> ineficiente.
 
Exato. Tenho visto bastante a utilização de "id" pra tudo. Consequentemente 
grande lentidão e falta de integridade. 


> Não entendi, comentar o quê?  Sem os significados, e o resto da
> estrutura e explicações, é impossível dizer qualquer coisa.  Modelagem
> de dados é o tipo de coisa muito difícil de fazer remotamente
> justamente pela quantidade de informações necessárias.

Viche... desculpe. Essa parte não era pra ter ido na verdade...  

 
> Em termos gerais, amiúde uma chave composta grande pode indicar falta
> de normalização, e portanto ou desatenção de quem modelou, ou
> desconhecimento — geralmente as pessoas entendem mal as formas normais,
> e até desconhecem qualquer coisa além da 3NF.  Só para lembrar, há sete
> formas normais (as 5NFs originais, a Boyce-Codd e a temporal, esta de
> difícil aplicação), mas geralmente o bom senso e uma análise atenta dá
> bons resultados mesmo conhecendo apenas as três primeiras formas
> normais.
> 
> Mas de fato há situações em que uma chave pode chegar a cobrir todos os
> atributos (naturais) de uma relação (não confundir com relacionamento).


Da minha parte, Dutra, hoje vc sanou todas as dúvidas que eu tinha. Tempos 
atrás, quando eu havia questionado pela primeira vez, não havia ficado claro e 
não me senti a vontade pra voltar a lista. Hoje está perfeito! 

Obrigado a todos.


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

[pgbr-geral] RES: RES: Chave Primaria Composta

[Márcio A . Sepp]

> Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha 
> ou "neta" da tabela.
> Mas assim, no que eu vi, na prática é o seguinte:
> 1 - A informação da chave, geralmente não é a que vc quer, então o join vai 
> acontecer igual


Gostaria de citar um exemplo prático:
Criar estrutura de 03 tabelas conforme entendido hoje na explanação do Dutra e 
do Tiago.

-- Tabela do lote contábil
CREATE TABLE public.lote
(
   documento character varying(20) NOT NULL, 
   data date, 
   PRIMARY KEY (documento)
);


-- Tabela de lançamentos contábeis
CREATE TABLE public.lancamento
(
   documento character varying(20) NOT NULL, 
   conta integer NOT NULL, 
   natureza character(1) NOT NULL, 
   valor numeric(10,2) NOT NULL,
   PRIMARY KEY (documento, conta, natureza), 
   FOREIGN KEY (documento) REFERENCES public.lote (documento) ON UPDATE CASCADE 
ON DELETE NO ACTION
);

(veja bem, a intenção aqui não é discutir o meu entendimento da contabilidade, 
é apenas mostrar um desenho ficticio de uma aplicação. Na prática pode e talvez 
deva ser diferente a estrutura)


-- Lançamento no centro de custo
CREATE TABLE public.lancamentoccu
(
   documento character varying(20), 
   conta integer, 
   natureza character(1), 
   codigo_ccu integer, 
   valor numeric(10,2) NOT NULL, 
   PRIMARY KEY (documento, conta, natureza, codigo_ccu), 
   FOREIGN KEY (documento, conta, natureza) REFERENCES public.lancamento 
(documento, conta, natureza) ON UPDATE CASCADE ON DELETE NO ACTION
);


Neste modelo, se eu quiser saber o total que foi debitado de um centro de custo 
em um determinado mês eu não preciso envolver a tabela de lançamento, pois a 
data está na tabela lote e o restante da informação que eu preciso está na 
tabela de lancamentoccu. (Não sei se essa prática é boa ou não...  por favor, 
comentem...), mas que é possível é... 

Agora, se eu tiver id em todas as tabelas, necessariamente será preciso passar 
por todas elas para chegar onde está a informação. Aí sim aumenta *muito* o 
tempo. 


> 2 - Os índices ficam bem maiores 
Sim. Porém no mesmo modelo acima, se eu não utilizasse chaves naturais eu teria 
de fazer da seguinte forma:

-- Tabela do lote contábil
CREATE TABLE public.lote
(
  id integer serial,
  documento character varying(20) NOT NULL,
  data date,
  CONSTRAINT PRIMARY KEY (id),
  CONSTRAINT UNIQUE (documento)
);

Observe que tem de criar o campo id a mais (que tbm consumirá espaço) e uma 
constraint no campo documento (que tbm consumirá espaço).
Já nas outras tabelas vc terá de, além de criar um campo a mais (id), também 
terá de criar uma fk pra tabela pai.

Na tabela lancamentoccu a coisa fica pior ainda, pois vc precisará também criar 
uma referência para a tabela lote. Caso contrário vc sacrifica a integridade da 
aplicação.

Por favor, Dutra, Adami e demais...  critiquem as minhas afirmações acima?

> 3 - Vc tem uma redundância de informações e maior consumo de espaço
> 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que você 
> precise unir 30 tabelas cada uma com 10 campos na sua chave,  > pense no 
> tamanha da instrução.
> O sistema em questão que eu citei anteriormente tem todos esses problemas e 
> hoje é um verdadeiro elefante branco.

O que daria também pra gente fazer é criar um banco de testes e verificar como 
ficam as coisas após uma certa carga. Daí mata isso de vez.


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

[pgbr-geral] RES: RES: RES: Chave Primaria Composta

[Márcio A . Sepp]

> > Por favor, Dutra, Adami e demais...  critiquem as minhas afirmações
> acima?
> 
> Não vou criticar não, para mm está bom.  É isso aí.
> 
> 
> > O que daria também pra gente fazer é criar um banco de testes e
> verificar como ficam as coisas após uma certa carga. Daí mata isso de
> vez.
> 
> Testar e experimentar sempre é bom, mas o que estamos falando já foi
> verificado à exaustão — além de decorrer do próprio modelo relacional e
> conceitos decorrentes.

Agradeço a vc Dutra, Tiago e Fabiano.
Da minha parte dou por encerrado. Só respondi este email antes para me 
certificar de ter entendido o conceito. 

Obrigado a todos


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

[pgbr-geral] RES: RES: RES: RES: Chave Primaria Composta

[Márcio A . Sepp]

> > Vários anos atrás vi na lista o Dutra falando sobre isso também e
> > participei das discussões afim de aprender mais. Pois até o momento
> > sempre usei ID's também.
> >
> > Tenho um produto ERP com mais ou menos 1.000 tabelas e refiz todas
> > para chaves naturais. Os pontos positivos e negativos que o Adami
> > citou também valeram para o meu caso.
> 
> Acho que vocês não sabem como isso me deixa feliz!

Então fique novamente, pois tbm estou nessa. 
Obrigado novamente!


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

[pgbr-geral] Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Márcio A . Sepp]

Boa noite,


Alguma vantagem/desvantagem em se utilizar o FreeBSD como sistema
operacional para o servidor do PostgreSQL?
Encontrei algumas documentações bem antigas [1] que são favoráveis ao
FreeBSD. Eu particularmente tbm gosto mais dele. Mas estou por fora e se
alguém tiver alguma documentação mais atualizada, por favor, me envie... 

[1]
http://www.varlena.com/GeneralBits/Tidbits/perf.html#freebsd




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

[pgbr-geral] RES: Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Márcio A . Sepp]

> >> Estranho.  Na pior das hipóteses, pega-se o acionador de dispositivo
> >> (que tem de ser livre, em razão da GNU GPL) da distro ‘que funciona’
> >> e transfere-se para a preferida.  Ou tem algo mais complicado que
> isso?
> >
> > Havia uma controladora de discos a qual possuía os "drivers" ou
> > acionadores de dispositivos de código fechado disponível apenas em
> > pacotes RPM.
> 
> Se fosse questão de empacotamento, bastava abrir ou converter, é
> trivial.  Mas não devia ser, devia ser compatibilidade; provavelmente
> seria o caso de usar a mesma versão de núcleo e relatar para os
> desenvolvedores a violação da GNU GPL, mas a solução definitiva.
> provavelmente demoraria meses.
 

Quanto a questão de sistema de arquivos. Há vantagens em se utilizar o ufs?  


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

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

[Márcio A . Sepp]

Bom dia,


Quais os prós e contras de usar tipos compostos em campos da chave primária?



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

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

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

Tipos compostos em chaves primárias. 

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

Entendo. O questionamento realmente é o outro.

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

Exemplo hipotético:

CREATE TYPE public.tanimal AS
   (especie integer,
chip integer);

CREATE TABLE public.animal
(
  identificacao tanimal NOT NULL,
  nascimento timestamp with time zone,
  CONSTRAINT animal_pkey PRIMARY KEY (identificacao)
)

Numa modelagem tradicional eu teria na tabela (hipotética) de animal os campos 
especie e chip como chave primária, pois para cada especie de animal eu posso 
ter um chip de tamanhos diferentes e a numeração digamos que possa se repetir 
entre os diferentes tipos de chips. 

Que vantagens/desvantagens eu teria em utilizar esta abordagem ao invés de 
utilizar a tradicional? 
Onde pode ser aplicado um tipo composto e que ele se sairá melhor que a 
modelagem tradicional?


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

[pgbr-geral] RES: Sequence Jump 32

[Márcio A . Sepp]

Só complementando as explicações do Euler e Dutra. Pense o que aconteceria se 
vc iniciasse uma transação, desse um next_sequence e lá pelas tantas 
abandonasse a transação sem commitar? 
Se vc não quer esses "buracos", faça um controle conforme o Dutra explicou. 


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

[pgbr-geral] Ajuda com definição

[Márcio A . Sepp]

Boa tarde,



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.
O problema disso é que se eu criar o campo como sendo integer, lá pelas
tantas corro o risco de dar violação de PK.

As soluções possíveis seriam criar o campo como varchar(7) ou colocar um
segundo campo na chave para identificar a informação.

A considerar:
99,9% dos registros desta tabela são de tamanho 7.

Dutra e demais da lista, qual a forma mais correta de modelar isso?


--
Att.
Márcio

 

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

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

[Márcio A . Sepp]

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

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


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

[pgbr-geral] RES: PostgreSQL 10 lançado

[Márcio A . Sepp]

 

Parabéns a todos os envolvidos no projeto, principalmente aos brasileiros. 
Entre eles o Euler e o Fabrízio e aos patrocinadores.

 

 

--

Att.

Márcio A. Sepp

 

De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de 
Fábio Telles Rodriguez
Enviada em: quinta-feira, 5 de outubro de 2017 15:25
Para: Comunidade PostgreSQL Brasileira
Assunto: Re: [pgbr-geral] PostgreSQL 10 lançado

 

Senhores, seria bom atualizar o site do postgresql.org.br e colocar a notícia 
do lançamento do PostgreSQL 10.

Atualizamos o site, mas não atualizamos o conteúdo. Seria um momento propicio 
para discutir isso, não?

 

Em 5 de outubro de 2017 12:50, Euler Taveira  escreveu:

O Grupo de Desenvolvimento Global do PostgreSQL anunciou hoje o
lançamento do PostgreSQL 10, a versão mais recente do banco de dados
de código aberto mais avançado do mundo.

Uma característica crítica das cargas de trabalho modernas é a
capacidade de distribuir dados em vários nós para acesso,
gerenciamento e análise mais rápidos, que também é conhecida como
estratégia de "divisão e conquista". O PostgreSQL 10 inclui melhorias
significativas para implementar efetivamente a estratégia de divisão e
conquista, incluindo replicação lógica nativa, partição declarativa de
tabelas e melhorias na funcionalidade de paralelismo de consultas.

"A nossa comunidade de desenvolvedores concentrou-se na construção de
recursos que aproveitariam as modernas configurações de infraestrutura
para distribuição de carga de trabalho", disse Magnus Hagander, um
membro do Grupo de Desenvolvimento Global do PostgreSQL.
"Funcionalidades como a replicação lógica e melhorias no paralelismo
de consultas representam anos de trabalho e demonstram a dedicação
continuada da comunidade para garantir a liderança do Postgres à
medida que as demandas de tecnologia evoluem".

Esta versão também marca a alteração do esquema de versão do
PostgreSQL para um formato "x.y". Isso significa que a próxima versão
corretiva do PostgreSQL será 10.1 e a próxima versão principal será
11.

* Replicação Lógica - Uma estrutura de publicação / assinatura para
distribuição de dados

A replicação lógica expande as funcionalidades de replicação atuais do
PostgreSQL com a capacidade de enviar modificações a nível de banco de
dados ou a nível de tabela para diferentes bancos de dados do
PostgreSQL. Os usuários agora podem decidir os dados a serem
replicados para vários clusters de banco de dados e terão a capacidade
de executar atualizações sem interrupção para as futuras versões
principais do PostgreSQL.

"Temos usado fortemente o PostgreSQL desde 9.3 e estamos muito
entusiasmados com a versão 10, pois traz a base para os tão esperados
particionamento e replicação lógica integrada. Ele nos permitirá usar
o PostgreSQL em mais serviços", disse Vladimir Borodin, DBA Chefe de
Equipe na Yandex.

* Particionamento Declarativo de Tabelas - Conveniência na divisão de seus dados

O particionamento de tabelas existe há anos no PostgreSQL, mas exigiu
que um usuário mantenha um conjunto de regras e gatilhos não triviais
para que o particionamento funcione. O PostgreSQL 10 apresenta uma
sintaxe de particionamento de tabelas que permite aos usuários criarem
e manterem facilmente tabelas particionadas por intervalo e lista. A
adição da sintaxe de particionamento é o primeiro passo em uma série
de funcionalidades planejadas para fornecer uma estrutura de
particionamento robusta no PostgreSQL.

* Melhor paralelismo de consulta - Conquiste rapidamente sua análise

O PostgreSQL 10 oferece um melhor suporte para consultas
paralelizadas, permitindo que mais partes do processo de execução da
consulta sejam paralelizadas. As melhorias incluem tipos adicionais de
varredura de dados que são paralelizados, bem como otimizações quando
os dados são recombinados, como preordenação. Esses aprimoramentos
permitem que os resultados sejam retornados mais rapidamente.

* Commit por Quórum para Replicação Síncrona - Distribua dados com confiança

O PostgreSQL 10 introduz o commit por quórum para a replicação
síncrona, o que permite flexibilidade na forma como um banco de dados
primário recebe confirmação de que as alterações foram gravadas com
sucesso nas réplicas remotas. Um administrador agora pode especificar
que, se um certo número de réplicas tiver reconhecido que uma
alteração no banco de dados foi feita, os dados podem ser considerados
como seguramente escritos.

"O commit por quórum para replicação síncrona no PostgreSQL 10 oferece
mais opções para expandir nossa capacidade de promover infraestrutura
de banco de dados, da perspectiva da aplicação, com tempo de
interrupção praticamente zero. Isso nos permite implantar e atualizar
continuamente nossa infraestrutura de banco de dados sem incorrer em
longas janelas de manutenção", disse Curt Micol. , Engenheiro de
infraestrutura pessoal na Simple Finance.

* Autenticação SCRAM-SHA-256 - Proteja seu

[pgbr-geral] RES: Migrando para Postgres

[Márcio A . Sepp]

Alguém já passou pela experiência de migrar um banco Firebird para Postgres? 
Como foi essa migração?

Atualmente em uma aplicação tenho um banco com pouco mais de 5GB e fico 
pensando se não teria mais performance, escalabilidade e outros controles 
(medição de uso) se migrasse para o Postgres.


--

Renato, não sou especialista na área, mas minha percepção é que são coisas bem 
distintas. O foco de um e do outro são públicos bem distintos (segundo a minha 
percepção apenas - não é baseado em nenhuma documentação). 

Não cheguei a trabalhar com a versão 3 do firebird (a última que trabalhei era 
na 2.5), mas creio que ainda exista uma lacuna grande pra este conseguir chegar 
ao nível de maturidade e recursos do postgres. 
No postgres há muitos recursos que não existiam no firebird 2.5. Cito alguns:
- Particionamento de tabelas: (no postgres ainda é meio chucro a coisa, mas 
tem);
- Tablespaces;
- Índices parciais;
- Agora nas últimas versões tem paralelismo (não sei como está isso no 
firebird); 
- Não há a necessidade de fazer dump/restore para otimizar;

Também o projeto do firebird eu acho que já não tem mais tanto espaço, pois tem 
muitos bancos bons na área...  acho que o firebird ficou em algum ponto entre 
um sqlite e um postgres. Tipow, parece-me que ele tá sem foco hoje... (minha 
percepção apenas).

Dependendo do teu sistema, talvez no firebird vc tem algumas vantagens, que 
seria a possibilidade do teu cliente apenas copiar um arquivo e estar feito o 
backup (não é o correto, mas na prática é assim que a maioria das vezes 
acontece). 

Vejo diversos sistemas aqui com firebird (versões 2.x) rodando na minha região, 
onde o banco chega a uns 15 Gigas e aih a coisa pipoca, obrigando os 
desenvolvedores a criar outros bancos e fazer gambiarras.

Faz uns testes aih em relação ao unicode e veja se está ok pra vc. Creio que vc 
não terá problemas no restante da aplicação.



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

[pgbr-geral] Definição

[Márcio A . Sepp]

Boa tarde,


Por favor, está correta esta definição ou estou fazendo algo que não deveria
ser feito pelo campo justamente ser chave?

create table t1
( c1t1  integer,
  c2t1  integer,
primary key (c1t1));


create table t2
( c1t1 integer,
  c2t2 integer,
  c3t2 integer,
primary key (c1t1, c2t2),
foreign key (c1t1) references t1 (c1t1),
unique (c2t2));



Att.
Márcio A. Sepp

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