Re: [pgbr-geral] Particionamento

[Fabrízio de Royes Mello]

On 20-05-2016 16:26, Fabrízio de Royes Mello wrote:
> On 20-05-2016 14:48, Felipe Santos wrote:
>>
>> Olá Danilo,
>>
>> Nenhum dos dois.
>>
>> Ele lê o índice do campo particionado nas tabelas filhas para saber se
>> deve entrar nos mesmos ou não.
>>
>> A trigger e os checks são acionados apenas nos eventos DML.
>>
> 
> Danilo,
> 
> Infelizmente vc está equivocado... 
> 
> [...]
> 

Oops... quis fizer Felipe...

Att,

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



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

Re: [pgbr-geral] Particionamento

[Fabrízio de Royes Mello]

On 20-05-2016 14:48, Felipe Santos wrote:
> 
> Olá Danilo,
> 
> Nenhum dos dois.
> 
> Ele lê o índice do campo particionado nas tabelas filhas para saber se
> deve entrar nos mesmos ou não.
> 
> A trigger e os checks são acionados apenas nos eventos DML.
> 

Danilo,

Infelizmente vc está equivocado... o que determina o ajuste no plano de
execução para ir ou não apenas em determinada(s) partição é a CHECK
CONSTRAINT. Veja o exemplo abaixo (pouco extenso):

=
1) Criar tabela e 3 particoes

fabrizio=# CREATE TABLE foo (id serial primary key, partkey date);
CREATE TABLE
fabrizio=# CREATE TABLE foo_20160520 () INHERITS (foo);
CREATE TABLE
fabrizio=# CREATE TABLE foo_20160521 () INHERITS (foo);
CREATE TABLE
fabrizio=# CREATE TABLE foo_20160522 () INHERITS (foo);
CREATE TABLE
fabrizio=# CREATE OR REPLACE FUNCTION foo_partition() RETURNS trigger AS
fabrizio-# $$
fabrizio$# BEGIN
fabrizio$#EXECUTE format('INSERT INTO %I VALUES (($1).*)',
'foo_'||to_char(NEW.partkey, 'FMMMDD'))
fabrizio$#USING NEW;
fabrizio$#RETURN NULL;
fabrizio$# END;
fabrizio$# $$
fabrizio-# LANGUAGE plpgsql;
CREATE FUNCTION
fabrizio=#
fabrizio=# CREATE TRIGGER foo_trigger BEFORE INSERT ON foo FOR EACH ROW
EXECUTE PROCEDURE foo_partition();
CREATE TRIGGER
fabrizio=# INSERT INTO foo (partkey) SELECT date '2016-05-20' + id%3
FROM generate_series(1,100) AS id;
INSERT 0 0
fabrizio=# SELECT count(*) FROM foo;
 count
---
   100
(1 row)


=
2) Executar algumas queries SEM a CHECK CONSTRAINT

fabrizio=# EXPLAIN (COSTS OFF) SELECT * FROM foo;
   QUERY PLAN

 Append
   ->  Seq Scan on foo
   ->  Seq Scan on foo_20160520
   ->  Seq Scan on foo_20160521
   ->  Seq Scan on foo_20160522
(5 rows)

fabrizio=# EXPLAIN (COSTS OFF) SELECT * FROM foo WHERE partkey =
'2016-05-20';
   QUERY PLAN

 Append
   ->  Seq Scan on foo
 Filter: (partkey = '2016-05-20'::date)
   ->  Seq Scan on foo_20160520
 Filter: (partkey = '2016-05-20'::date)
   ->  Seq Scan on foo_20160521
 Filter: (partkey = '2016-05-20'::date)
   ->  Seq Scan on foo_20160522
 Filter: (partkey = '2016-05-20'::date)
(9 rows)

fabrizio=# EXPLAIN (COSTS OFF) SELECT * FROM foo WHERE partkey =
'2016-05-21';
   QUERY PLAN

 Append
   ->  Seq Scan on foo
 Filter: (partkey = '2016-05-21'::date)
   ->  Seq Scan on foo_20160520
 Filter: (partkey = '2016-05-21'::date)
   ->  Seq Scan on foo_20160521
 Filter: (partkey = '2016-05-21'::date)
   ->  Seq Scan on foo_20160522
 Filter: (partkey = '2016-05-21'::date)
(9 rows)

fabrizio=# EXPLAIN (COSTS OFF) SELECT * FROM foo WHERE partkey BETWEEN
'2016-05-20' AND '2016-05-21';
  QUERY PLAN

---
 Append
   ->  Seq Scan on foo
 Filter: ((partkey >= '2016-05-20'::date) AND (partkey <=
'2016-05-21'::date))
   ->  Seq Scan on foo_20160520
 Filter: ((partkey >= '2016-05-20'::date) AND (partkey <=
'2016-05-21'::date))
   ->  Seq Scan on foo_20160521
 Filter: ((partkey >= '2016-05-20'::date) AND (partkey <=
'2016-05-21'::date))
   ->  Seq Scan on foo_20160522
 Filter: ((partkey >= '2016-05-20'::date) AND (partkey <=
'2016-05-21'::date))
(9 rows)


=
3) Adicionar as CHECK CONSTRAINTS

fabrizio=# EXPLAIN (COSTS OFF) SELECT * FROM foo;
   QUERY PLAN

 Append
   ->  Seq Scan on foo
   ->  Seq Scan on foo_20160520
   ->  Seq Scan on foo_20160521
   ->  Seq Scan on foo_20160522
(5 rows)

fabrizio=# EXPLAIN (COSTS OFF) SELECT * FROM foo WHERE partkey =
'2016-05-20';
   QUERY PLAN

 Append
   ->  Seq Scan on foo
 Filter: (partkey = '2016-05-20'::date)
   ->  Seq Scan on foo_20160520
 Filter: (partkey = '2016-05-20'::date)
(5 rows)

fabrizio=# EXPLAIN (COSTS OFF) SELECT * FROM foo WHERE partkey =
'2016-05-21';
   QUERY PLAN

 Append
   ->  Seq Scan on foo
 Filter: (partkey = '2016-05-21'::date)
   ->  Seq Scan on foo_20160521
 Filter: (partkey = '2016-05-21'::date)
(5 rows)

fabrizio=# EXPLAIN (COSTS OFF) SELECT * FROM foo WHERE partkey BETWEEN
'2016-05-20' AND '2016-05-21';
  QUERY PLAN

---
 Append
   ->  Seq Scan on foo
 Filter: ((partkey >= '2016-05-20'::date) AND (partkey <=
'2016-05-21'::date))
   ->  Seq Scan on foo_20160520
 Filter: ((partkey >= 

Re: [pgbr-geral] Particionamento

[Felipe Santos]

Em 20 de maio de 2016 14:43, Danilo Silva 
escreveu:

> Pessoal,
>
> Em uma consulta, envolvendo tabelas particionadas, o postgres considera a
> trigger da tabela pai ou o check constraint das tabelas filhas para ir
> direto na tabela onde estão os dados?
>
> []s
> Danilo
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Olá Danilo,

Nenhum dos dois.

Ele lê o índice do campo particionado nas tabelas filhas para saber se deve
entrar nos mesmos ou não.

A trigger e os checks são acionados apenas nos eventos DML.

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

[pgbr-geral] Particionamento

[Danilo Silva]

Pessoal,

Em uma consulta, envolvendo tabelas particionadas, o postgres considera a
trigger da tabela pai ou o check constraint das tabelas filhas para ir
direto na tabela onde estão os dados?

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

Re: [pgbr-geral] Particionamento

[Flavio Henrique Araque Gurgel]

2) o planejador não gosta de between para excluir partições,
tente usar comparações simples com =  



Uh? Como assim? Pelo menos nas versões mais recentes `foo BETWEEN bar
AND baz` é exatamente equivalente a `foo = bar AND foo = baz`. Não
vejo como isso afetaria o particionamento, será que pode ter sido mudado
em versões mais recentes?

Nem do between nem do extract(year from... )


Do BETWEEN tudo bem, mas do EXTRACT realmente não vai dar certo. No caso
de particionamento de datas é melhor usar o campo data diretamente e
compará-lo sem passar por funções, a não ser que nas consultas você
sempre utilize a função também, mas ficaria trabalhoso:

 SELECT ... FROM ... WHERE extract(year from dt) = 2014 AND dt =
'2014-07-03 00:00:00';

Num rola né?!

Mas no caso do between ele converteu pra = e =


Sim, eu não espero nenhuma diferença em termos de performance usando
BETWEEN ou o par = e =. Até olhando no gram.y, dá pra ver que é uma
transformação feita direto no parser [1]. Fico imaginando agora se estou
deixando algo bobo passar.


A última vez que fiz um particionamento brabo envolvendo datas na chave 
de particionamento foi com a versão 8.3.
Se eu usasse between, o planejador não excluía as partições indesejadas 
e, por isso, eu usava sempre os comparadores mais simples.


Acredito que a coisa mudou a partir da versão 8.4 quando foi inserido o 
modo partition para a GUC constraint_exclusion mas não estou com tempo 
pra olhar o fonte e pesquisar agora, todavia, nas versões mais recentes, 
Matheus já nos deu a prosa ;)


[]s
Flavio Gurgel



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

Re: [pgbr-geral] Particionamento

[Bruno Silva]

2014-07-04 4:21 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com:

 A última vez que fiz um particionamento brabo envolvendo datas na chave de
 particionamento foi com a versão 8.3.
 Se eu usasse between, o planejador não excluía as partições indesejadas e,
 por isso, eu usava sempre os comparadores mais simples.

 Acredito que a coisa mudou a partir da versão 8.4 quando foi inserido o
 modo partition para a GUC constraint_exclusion mas não estou com tempo pra
 olhar o fonte e pesquisar agora, todavia, nas versões mais recentes,
 Matheus já nos deu a prosa ;)

 []s
 Flavio Gurgel


Só complementando, quando criei o check com between o parser o modificou
para = e = , ou seja acabou ficando da forma como você disse Flávio.
Mas foi bem interessante olhar o código do Postgres, ainda não tinha visto.
Matheus, é desse trecho que você fala né?
| a_expr BETWEEN opt_asymmetric b_expr AND b_expr   %prec BETWEEN
11055
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11055
{
11056
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11056
$$ = makeAndExpr(
11057
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11057
(Node *) makeSimpleA_Expr(AEXPR_OP, =, $1, $4, @2),
11058
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11058
(Node *) makeSimpleA_Expr(AEXPR_OP, =, $1, $6, @2),
11059
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11059
 @2);
11060
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11060
}


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

Re: [pgbr-geral] Particionamento

[Matheus de Oliveira]

2014-07-04 8:17 GMT-03:00 Bruno Silva bemanuel...@gmail.com:

 Mas foi bem interessante olhar o código do Postgres, ainda não tinha visto.
 Matheus, é desse trecho que você fala né?
 | a_expr BETWEEN opt_asymmetric b_expr AND b_expr   %prec BETWEEN
 11055
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11055
 {
 11056
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11056
 $$ = makeAndExpr(
 11057
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11057
 (Node *) makeSimpleA_Expr(AEXPR_OP, =, $1, $4, @2),
 11058
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11058
 (Node *) makeSimpleA_Expr(AEXPR_OP, =, $1, $6, @2),
 11059
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11059
  @2);
 11060
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11060
 }


Sim. Veja que ele, logo no parser, converte a expressão `x BETWEEN y AND z`
para os pares `x = y AND x = z`. Os valores do cifrão são posicionais,
daí $1 = a_expr (x), $2 = BETWEEN, $3 = opt_asymetric, $4 = b_expr (y), $5
= AND, $6 = b_expr (z). Daí o makeSimpleA_Expr cri as expressões `x = y`
(linha 11057) e `x = z` (linha 11058) e a chamada de fora do makeAndExpr
(11056) junta essas duas num AND. O $$ podemos pensar como um retorno
feito nessa parte do parser, como se esse bloco fosse uma função e o $$
fosse o return dela (não é exatamente isso, mas seria uma mapeamento
razoável).

É interessante dar uma olhada no código quando esse tipo de dúvida surge.
Eu já havia buscado essa há um tempo durante um treinamento, exatamente
para dirimir dúvidas que surgiram sobre a diferença entre usar BETWEEN os
pares = e =.

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento

[Fabrízio de Royes Mello]

On 03-07-2014 18:37, Bruno Silva wrote:
 On Thu, Jul 3, 2014 at 5:10 PM, Bruno Silva bemanuel...@gmail.com wrote:
 
 ALTER TABLE base.filho_2013 ADD CONSTRAINT filho_check_2013 CHECK ( dta
 between '2013-01-01 00:00:00' AND '2013-12-31 23:59:59' );
 
 Pessoal, o problema estava aqui.
 Tinha 3 das tabelas filha que estava com a Constraint dessa forma:
 CHECK ( extract( year from dta )=2010);
 
 Após deixar da forma 'dta between ... ' resolveu.
 

Em tempo, recomendo dar uma lida na série de posts [1][2][3][4] que o
Telles fez sobre particionamento no PostgreSQL. É bem interessante, tem
nos minimos detalhes o que precisa ser feito e os cuidados que precisa ter.

Infelizmente a implementação atual é na verdade um workaround (pra não
dizer gambiarra) aproveitando o recurso de herança de tabelas (uma
caracteristica objeto-relacional do postgres) com alguns ajustes no
planejador para ele poder montar planos de execução eliminando partições
desnecessárias.

Não sei se pra 9.5 (por conta do tempo), mas já temos uma lista de
requisitos iniciais e será iniciado em breve o desenvolvimento do
particionamento declarativo no postgres. Quando eu tiver dados mais
concretos informo a todos.

Att,

[1] http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-quando/
[2] http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-como/
[3]
http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-detalhes/
[4]
http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-automatizando/

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Particionamento

[Bruno Silva]

Boa tarde pessoal, estive seguindo uns modelos de particionamento de
tabelas, tenho uma tabela com uns 50G, que estou usando numa base DW que
está sendo criada.
Porém não sei por que o particionamento não funciona.

Tenho a tabela Pai, a qual uso o campo dta como base para o particionamento
Criei as tabelas filho, com o seguinte comando:
begin;
CREATE TABLE base.filho_2013 (LIKE base.pai INCLUDING ALL) INHERITS
(base.pai);
ALTER TABLE base.filho_2013 no inherit base.pai;
INSERT INTO base.filho_2013 select * from base.pai WHERE dta between
'2013-01-01 00:00:00' and '2013-12-31 23:59:59';
DELETE FROM base.pai where dta BETWEEN '2013-01-01 00:00:00' and
'2013-12-31 23:59:59';
ALTER TABLE base.filho_2013 inherit base.pai;
ALTER TABLE base.filho_2013 ADD CONSTRAINT filho_check_2013 CHECK ( dta
between '2013-01-01 00:00:00' AND '2013-12-31 23:59:59' );
COMMIT;

Fiz isso pra mais outros anos ( 2010,2011,2012,... )
Porém quando faço as consultas ele verifica em todas as tabelas e não as
particionadas.
Ex.:
explain select * from base.pai where dta between '2010-01-01 00:00:00' and
'2010-12-31 23:59:59';

 QUERY PLAN

-
 Append  (cost=0.56..2396451.65 rows=6158379 width=707)
   -  Index Scan using ix_pai_01 on pai  (cost=0.56..1591444.27 rows=9496
width=699)
 Index Cond: ((dta = '2010-01-01 00:00:00-03'::timestamp with time
zone) AND (dta = '2010-12-31 23:59:59-03'::timestamp with time zone))
   -  Index Scan using ix_filho_2008_01 on filho_2008  (cost=0.43..8.45
rows=1 width=693)
 Index Cond: ((dta = '2010-01-01 00:00:00-03'::timestamp with time
zone) AND (dta = '2010-12-31 23:59:59-03'::timestamp with time zone))
   -  Index Scan using ix_filho_2013_01 on filho_2013
 (cost=0.56..500612.83 rows=1 width=690)
 Index Cond: ((dta = '2010-01-01 00:00:00-03'::timestamp with time
zone) AND (dta = '2010-12-31 23:59:59-03'::timestamp with time zone))
   -  Index Scan using ix_filho_2012_01 on filho_2012  (cost=0.43..8.46
rows=1 width=683)
 Index Cond: ((dta = '2010-01-01 00:00:00-03'::timestamp with time
zone) AND (dta = '2010-12-31 23:59:59-03'::timestamp with time zone))
   -  Index Scan using ix_filho_2011_01 on filho_2011  (cost=0.43..8.46
rows=1 width=674)
 Index Cond: ((dta = '2010-01-01 00:00:00-03'::timestamp with time
zone) AND (dta = '2010-12-31 23:59:59-03'::timestamp with time zone))
   -  Seq Scan on filho_2010  (cost=0.00..304369.18 rows=6148879 width=707)
 Filter: ((dta = '2010-01-01 00:00:00-03'::timestamp with time
zone) AND (dta = '2010-12-31 23:59:59-03'::timestamp with time zone))


Que fiz de errado?
Obs.: ainda tem registros na tabela pai.

Bruno E. A. Silva.
Analista de Sistemas.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento

[Matheus de Oliveira]

On Thu, Jul 3, 2014 at 5:10 PM, Bruno Silva bemanuel...@gmail.com wrote:

 begin;
 CREATE TABLE base.filho_2013 (LIKE base.pai INCLUDING ALL) INHERITS
 (base.pai);
 ALTER TABLE base.filho_2013 no inherit base.pai;
 INSERT INTO base.filho_2013 select * from base.pai WHERE dta between
 '2013-01-01 00:00:00' and '2013-12-31 23:59:59';
 DELETE FROM base.pai where dta BETWEEN '2013-01-01 00:00:00' and
 '2013-12-31 23:59:59';
 ALTER TABLE base.filho_2013 inherit base.pai;
 ALTER TABLE base.filho_2013 ADD CONSTRAINT filho_check_2013 CHECK ( dta
 between '2013-01-01 00:00:00' AND '2013-12-31 23:59:59' );
 COMMIT;


Primeiro, não precisa de colocar o INHERIT, tirar (ALTER TABLE ... NO
INHERIT) e depois colocar novamente (ALTER TABLE ... INHERIT). Para deletar
os dados *somente* da tabela pai, você pode usar o ONLY:

DELETE FROM ONLY(base.pai) where dta BETWEEN '2013-01-01 00:00:00' and
'2013-12-31 23:59:59';

Segundo, você esqueceu de adicionar uma check constraint nas tabelas filhas
para que o constraint exclusion funcione:

ALTER TABLE base.filho_2013 ADD CHECK(dta BETWEEN '2013-01-01 00:00:00'
and '2013-12-31 23:59:59');

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento

[Bruno Silva]

2014-07-03 17:22 GMT-03:00 Matheus de Oliveira matioli.math...@gmail.com:

 Segundo, você esqueceu de adicionar uma check constraint nas tabelas
 filhas para que o constraint exclusion funcione:

 ALTER TABLE base.filho_2013 ADD CHECK(dta BETWEEN '2013-01-01
 00:00:00' and '2013-12-31 23:59:59');


Matheus, eu esqueci de colocar só no email :-)


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

Re: [pgbr-geral] Particionamento

[Flavio Henrique Araque Gurgel]

Em 03/07/2014 22:24, Bruno Silva bemanuel...@gmail.com escreveu:


 2014-07-03 17:22 GMT-03:00 Matheus de Oliveira matioli.math...@gmail.com
:

 Segundo, você esqueceu de adicionar uma check constraint nas tabelas
filhas para que o constraint exclusion funcione:

 ALTER TABLE base.filho_2013 ADD CHECK(dta BETWEEN '2013-01-01
00:00:00' and '2013-12-31 23:59:59');


 Matheus, eu esqueci de colocar só no email :-)


1) verifique a configuração constraint_exclusion que deve estar partition
ou on (depende da versão)
2) o planejador não gosta de between para excluir partições,  tente usar
comparações simples com =  

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

Re: [pgbr-geral] Particionamento

[Bruno Silva]

On Thu, Jul 3, 2014 at 5:10 PM, Bruno Silva bemanuel...@gmail.com wrote:

 ALTER TABLE base.filho_2013 ADD CONSTRAINT filho_check_2013 CHECK ( dta
 between '2013-01-01 00:00:00' AND '2013-12-31 23:59:59' );

Pessoal, o problema estava aqui.
Tinha 3 das tabelas filha que estava com a Constraint dessa forma:
CHECK ( extract( year from dta )=2010);

Após deixar da forma 'dta between ... ' resolveu.

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

Re: [pgbr-geral] Particionamento

[Matheus de Oliveira]

2014-07-03 19:12 GMT-03:00 Bruno Silva bemanuel...@gmail.com:

 2) o planejador não gosta de between para excluir partições,  tente usar
 comparações simples com =  



Uh? Como assim? Pelo menos nas versões mais recentes `foo BETWEEN bar AND
baz` é exatamente equivalente a `foo = bar AND foo = baz`. Não vejo como
isso afetaria o particionamento, será que pode ter sido mudado em versões
mais recentes?

Nem do between nem do extract(year from... )


Do BETWEEN tudo bem, mas do EXTRACT realmente não vai dar certo. No caso de
particionamento de datas é melhor usar o campo data diretamente e
compará-lo sem passar por funções, a não ser que nas consultas você sempre
utilize a função também, mas ficaria trabalhoso:

SELECT ... FROM ... WHERE extract(year from dt) = 2014 AND dt =
'2014-07-03 00:00:00';

Num rola né?!

Mas no caso do between ele converteu pra = e =


Sim, eu não espero nenhuma diferença em termos de performance usando
BETWEEN ou o par = e =. Até olhando no gram.y, dá pra ver que é uma
transformação feita direto no parser [1]. Fico imaginando agora se estou
deixando algo bobo passar.

[1]
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;h=ba7d091dc793c079481a9a0fab05a110c8e98ce7;hb=HEAD#l11054

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento de tabela

[Danilo Silva]

Em 21 de fevereiro de 2014 12:55, Flavio Henrique Araque Gurgel 
fha...@gmail.com escreveu:



 Em 21-02-2014 16:48, Danilo Silva escreveu:


 1º Deletar registros mais antigos, algo em torno de 10 milhões de
 registros;
 2º Particionar a tabela;

 Penso em utilizar a 2ª opção visto ter acesso aos dados sem precisar
 modificar a aplicação (que é para ambiente web).

 Para a 2º opção o que vocês recomendam? Sei dos procedimentos para
 particionar tabelas (criar as tabelas filhas, criar as triggers, etc),
 mas a minha dúvida está na questão que a tabela já tem dados, como
 proceder neste caso, visto que a tabela não é pequena?




 Sobre os dados antigos, se você adotar uma coluna data como
 particionadora, você pode justamente colocar a tabela antiga como filha do
 particionamento, e removê-la quando não precisar mais dela.


Neste caso eu tenho que criar uma tabela que será a pai, e tabela atual,
que virará filha eu apenas faço um ALTER TABLE, alterando o nome da tabela
e colocando ela como INHERITS da nova tabela pai? Tenho algumas views que
se utilizam dessa tabela, como ficará, pois se alterar o nome,
automaticamente será alterado o nome nas views, terei que dar um
drop/create nas views?


 Cuidado com o particionamento: ele pode ajudar e também atrapalhar.
 Verifique se seus SELECTs e UPDATEs tocarão mais que uma partição depois
 que o particionamento ocorrer. Se isto for verdadeiro, cabe um estudo pra
 ver se o custo dos SELECTs e UPDATEs não vai aumentar ao invés de diminuir.

 Enfim, pese tudo antes de sair fazendo, pra realmente ter um ganho.


Realmente cabe um estudo de performance, pois a chave do particionamento
será com base em um campo data.

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

[pgbr-geral] Particionamento de tabela

[Danilo Silva]

Pessoal,

Utilizo postgresql 9.1.9 em servidor debian.

Tenho uma tabela (principal tabela do banco de dados) que está com 18
milhões de registros e ocupando 21 GB de espaço.

Essa tabela é de histórico de leituras, portando muito utilizanda, tanto
para select quanto para inserts e updates.

Para ter um melhor desempenho, tenho duas opções:

1º Deletar registros mais antigos, algo em torno de 10 milhões de registros;
2º Particionar a tabela;

Penso em utilizar a 2ª opção visto ter acesso aos dados sem precisar
modificar a aplicação (que é para ambiente web).

Para a 2º opção o que vocês recomendam? Sei dos procedimentos para
particionar tabelas (criar as tabelas filhas, criar as triggers, etc), mas
a minha dúvida está na questão que a tabela já tem dados, como proceder
neste caso, visto que a tabela não é pequena?

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

Re: [pgbr-geral] Particionamento de tabela

[Flavio Henrique Araque Gurgel]

Em 21-02-2014 16:48, Danilo Silva escreveu:


1º Deletar registros mais antigos, algo em torno de 10 milhões de registros;
2º Particionar a tabela;

Penso em utilizar a 2ª opção visto ter acesso aos dados sem precisar
modificar a aplicação (que é para ambiente web).

Para a 2º opção o que vocês recomendam? Sei dos procedimentos para
particionar tabelas (criar as tabelas filhas, criar as triggers, etc),
mas a minha dúvida está na questão que a tabela já tem dados, como
proceder neste caso, visto que a tabela não é pequena?


Escolha uma boa chave de particionamento, é o primeiro passo. Qual 
coluna será a que você usará como determinadora da partição.


Como você disse que é uma tabela de histórico, onde se faz delete dos 
dados antigos, provavelmente usar uma coluna com a data como chave pode 
ser uma boa ideia, pois remover os dados antigos depois sera um mero 
drop table.


Sobre os dados antigos, se você adotar uma coluna data como 
particionadora, você pode justamente colocar a tabela antiga como filha 
do particionamento, e removê-la quando não precisar mais dela.


Cuidado com o particionamento: ele pode ajudar e também atrapalhar. 
Verifique se seus SELECTs e UPDATEs tocarão mais que uma partição depois 
que o particionamento ocorrer. Se isto for verdadeiro, cabe um estudo 
pra ver se o custo dos SELECTs e UPDATEs não vai aumentar ao invés de 
diminuir.


Enfim, pese tudo antes de sair fazendo, pra realmente ter um ganho.

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

Re: [pgbr-geral] Particionamento de tabela

[Flávio Granato]

On 21-02-2014 12:48, Danilo Silva wrote:
 1º Deletar registros mais antigos, algo em torno de 10 milhões de registros;

Eu já acho que deveria seguir a primeira opção, minha visão para dados
antigos é para consultas históricas e não em base de produção. Se este
for seu caso é claro...


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

Re: [pgbr-geral] Particionamento de tabela

[Lucio Chiessi [VORio]]

Em 21/02/2014 12:48, Danilo Silva escreveu:

Pessoal,

Utilizo postgresql 9.1.9 em servidor debian.

Tenho uma tabela (principal tabela do banco de dados) que está com 18
milhões de registros e ocupando 21 GB de espaço.

Essa tabela é de histórico de leituras, portando muito utilizanda, tanto
para select quanto para inserts e updates.

Para ter um melhor desempenho, tenho duas opções:

1º Deletar registros mais antigos, algo em torno de 10 milhões de registros;
2º Particionar a tabela;

Penso em utilizar a 2ª opção visto ter acesso aos dados sem precisar
modificar a aplicação (que é para ambiente web).

Para a 2º opção o que vocês recomendam? Sei dos procedimentos para
particionar tabelas (criar as tabelas filhas, criar as triggers, etc),
mas a minha dúvida está na questão que a tabela já tem dados, como
proceder neste caso, visto que a tabela não é pequena?

[]s
Danilo


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



Olá Danilo.

Eu também te recomendaria a 2ª opção, para que não tenhas que excluir 
informações do seu banco que podem ser necessárias no futuro.


Mas avalie bem e planeje como vai ser a sua condição de particionamento 
(ex.: por data, tipo e etc) e crie as tabelas filhas, nunca esquecendo 
de criar também as constraint de checks em cada delas.


E nunca se esqueça que a partir dai, as suas queries irão ter que levar 
em consideração esta condição logica definida nas checks.   O otimizados 
de consultas do Postgres utiliza isto pra determinar em qual(is) 
partição(ões) ele vai buscar a(s) informação(ões) que a sua query pede.


Caso não faça isso, o otimizador de query pode realizar um seq_scan em 
todas as tabelas filhas (partições) e com isso criar uma situação muito 
ruim em desempenho.


De uma boa olhada na documentação em 
http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html


Após vc ter feito isto tudo, vc pode ativar as triggers que deve fazer 
para distribuir os dados nas partições quando forem inseridos.


A partir disto, se estiver tudo correto, irão fazer as buscas (por 
indice ou sequenciais) na partição filha correspondente e na tabela pai.


Enquanto vc nao mover as info antiga da tabela pai pras filhas, elas 
serão encontradas na pai.   E com o tempo, vc vai movendo as linhas da 
tabela pai para as tabelas filhas (partições) nas madrugadas ou em 
janelas de manutenção, como preferir.


Mas lembre-se de ter tudo isso planejado passo a passo e se possível, 
testado antes em uma copia do banco de testes.


Boa sorte pra vc e abraços!

--
Lucio Chiessi
Rio de Janeiro - Brasil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento de tabela

[Flávio Granato]

On 21-02-2014 13:16, Lucio Chiessi [VORio] wrote:
 Eu também te recomendaria a 2ª opção, para que não tenhas que excluir
 informações do seu banco que podem ser necessárias no futuro.

Tirar (entenda-se excluir) não significa apagar ou ficar inacessível.

Pode até ficar em outro repositório de dados, se são somente dados
históricos e não necessários para as atuais consultas...
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento parte 1 - Quando

[Fábio Telles Rodriguez]

Em 12 de janeiro de 2013 20:22, Fábio Telles Rodriguez 
fabio.tel...@gmail.com escreveu:

 Em 9 de janeiro de 2013 23:10, Fábio Telles Rodriguez 
 fabio.tel...@gmail.com escreveu:

 Parte 2 - COMO publicada!

 Ainda faltam 2 partes, espero escrever a 3ª parte até o final da semana.


 3ª Parte publicada:
 http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-detalhes/

 Agora só falta a última parte, uma função para automatizar a criação de
 partições.


4ª e última parte publicada:
http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-automatizando/

[]s
-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/
avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

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

Re: [pgbr-geral] Particionamento parte 1 - Quando

[Fábio Telles Rodriguez]

Em 9 de janeiro de 2013 23:10, Fábio Telles Rodriguez 
fabio.tel...@gmail.com escreveu:

 Parte 2 - COMO publicada!

 Ainda faltam 2 partes, espero escrever a 3ª parte até o final da semana.


3ª Parte publicada:
http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-detalhes/

Agora só falta a última parte, uma função para automatizar a criação de
partições.

[]s
-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/
avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

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

Re: [pgbr-geral] Particionamento parte 1 - Quando

[JotaComm]

Fabio,

Em 10 de janeiro de 2013 22:57, Fábio Telles Rodriguez 
fabio.tel...@gmail.com escreveu:

 Em 10 de janeiro de 2013 10:48, Fabrízio de Royes Mello 
 fabriziome...@gmail.com escreveu:


 2013/1/10 Fábio Telles Rodriguez fabio.tel...@gmail.com
 
 
  Boa, vou atualizar isso. Acho que vale uma conversa aprofundada para
 esse item.

 Sendo uma conversa regada a uma boa cerveja está valendo... :-)


 Então, fui tomar uma cerva com o povo aqui no trampo... e dei uma mega
 atualizada no texto. Incluí bastante coisa, mas acho que ainda vão mais 2
 posts para terminar de cobrir o assunto. Claro, o último post vai ser
 aquela função para automatizar tudo... :-)


Eu nem vou te contar quantas tabelas particionadas o sistema aqui tem,
senão tenho certeza que você vai querer me bater :(

Se eu puder contribuir de alguma maniera, estou à disposição.


 []s
 --
 Atenciosamente,
 Fábio Telles Rodriguez
 blog: http:// 
 http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/
 avepoint.blog.br
 e-mail / gtalk / MSN: fabio.tel...@gmail.com
 Skype: fabio_telles

 Timbira - A empresa brasileira de Postgres
 http://www.timbira.com.br

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



Abraços
-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento parte 1 - Quando

[Fábio Telles Rodriguez]

Em 11 de janeiro de 2013 11:59, JotaComm jota.c...@gmail.com escreveu:

 Fabio,

 Em 10 de janeiro de 2013 22:57, Fábio Telles Rodriguez 
 fabio.tel...@gmail.com escreveu:

 Em 10 de janeiro de 2013 10:48, Fabrízio de Royes Mello 
 fabriziome...@gmail.com escreveu:


 2013/1/10 Fábio Telles Rodriguez fabio.tel...@gmail.com
 
 
  Boa, vou atualizar isso. Acho que vale uma conversa aprofundada para
 esse item.

 Sendo uma conversa regada a uma boa cerveja está valendo... :-)


 Então, fui tomar uma cerva com o povo aqui no trampo... e dei uma mega
 atualizada no texto. Incluí bastante coisa, mas acho que ainda vão mais 2
 posts para terminar de cobrir o assunto. Claro, o último post vai ser
 aquela função para automatizar tudo... :-)


 Eu nem vou te contar quantas tabelas particionadas o sistema aqui tem,
 senão tenho certeza que você vai querer me bater :(


Eu tenho dois sistemas com várias tabelas particionadas também, umas 30


 Se eu puder contribuir de alguma maniera, estou à disposição.


Claro que tem... se você achar algum bug ou algo que seria interessante
acrescentar, eu já arrumo ou incluo nos próximos posts.

[]s
-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/
avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

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

Re: [pgbr-geral] Particionamento parte 1 - Quando

[Aldrey Galindo]

Grande Fábio,

   Vou acompanhar a série dos posts, muito interessante.

Atenciosamente,
Aldrey Galindo

Em 9 de janeiro de 2013 22:46, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 2013/1/9 Fábio Telles Rodriguez fabio.tel...@gmail.com

 Parte 2 - COMO publicada!


 Excelente... se me permite, uma dica... o CREATE TABLE ... (LIKE ...)
 desde a 9.0 vc pode usar a cláusula INCLUDING ALL, assim ele vai copiar
 DEFAULTS, INDEXES, CONSTRAINTS (aqui ele vai copiar a check, é o
 comportamento normal), COMMENTS e STORAGE (parametros)... então dá pra
 fazer:

 CREATE TABLE pedido_2008 (LIKE pedido INCLUDING ALL) INHERITS (pedido);

 Eu particularmente, para não emitir aqueles NOTICES prefiro assim:

 CREATE TABLE pedido_2008 (LIKE pedido INCLUDING ALL);
 ALTER TABLE pedido_2008 INHERIT pedido;


 Ainda faltam 2 partes, espero escrever a 3ª parte até o final da semana.


 Aguardamos anciosos... :-)

 Att,

 --
 Fabrízio de Royes Mello
 Consultoria/Coaching PostgreSQL
  Blog sobre TI: http://fabriziomello.blogspot.com
  Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
  Twitter: http://twitter.com/fabriziomello

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




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

Re: [pgbr-geral] Particionamento parte 1 - Quando

[Fábio Telles Rodriguez]

Em 9 de janeiro de 2013 23:46, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 2013/1/9 Fábio Telles Rodriguez fabio.tel...@gmail.com

 Parte 2 - COMO publicada!


 Excelente... se me permite, uma dica... o CREATE TABLE ... (LIKE ...)
 desde a 9.0 vc pode usar a cláusula INCLUDING ALL, assim ele vai copiar
 DEFAULTS, INDEXES, CONSTRAINTS (aqui ele vai copiar a check, é o
 comportamento normal), COMMENTS e STORAGE (parametros)... então dá pra
 fazer:


Boa, vou atualizar isso. Acho que vale uma conversa aprofundada para esse
item.
Uma ideia seria mostrar como se virar com versões anteriores ah...
nada, tem que usar 9.2 e pronto, hahahaha.


 CREATE TABLE pedido_2008 (LIKE pedido INCLUDING ALL) INHERITS (pedido);

 Eu particularmente, para não emitir aqueles NOTICES prefiro assim:

 CREATE TABLE pedido_2008 (LIKE pedido INCLUDING ALL);
 ALTER TABLE pedido_2008 INHERIT pedido;


Bom, aí já é uma questão de gosto... :-P



  Ainda faltam 2 partes, espero escrever a 3ª parte até o final da semana.


 Aguardamos anciosos... :-)

 Att,

 --
 Fabrízio de Royes Mello
 Consultoria/Coaching PostgreSQL
  Blog sobre TI: http://fabriziomello.blogspot.com
  Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
  Twitter: http://twitter.com/fabriziomello

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




-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/
avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

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

Re: [pgbr-geral] Particionamento parte 1 - Quando

[Fabrízio de Royes Mello]

2013/1/10 Fábio Telles Rodriguez fabio.tel...@gmail.com


 Boa, vou atualizar isso. Acho que vale uma conversa aprofundada para esse
item.

Sendo uma conversa regada a uma boa cerveja está valendo... :-)



 Uma ideia seria mostrar como se virar com versões anteriores ah...
nada, tem que usar 9.2 e pronto, hahahaha.


Sobre a 9.2 concordo... temos que encorajar todos a migrar para essa versão
que está muito boa... e se alguém estiver tendo problemas compartilhe
conosco e/ou comunidade internacional, pq só o fato de usar a nova versão e
reportar possíveis problemas já é uma baita colaboração com o
desenvolvimento e evolução do nosso paquiderme.

Para versões mais antigas era mais complicadinho mesmo... eu tive que
implementar algumas PLs para clonar coisas (indices, constraints,
parametros, etc) da tabela pai para a filha pq nao tinha ainda os recursos
que tem hoje... (estou falando de versões tipo a 8.2).

Vou colocar esses carinhas la no github.com/fabriziomello e dai quem
precisar pode usar a vontade.



 CREATE TABLE pedido_2008 (LIKE pedido INCLUDING ALL) INHERITS (pedido);

 Eu particularmente, para não emitir aqueles NOTICES prefiro assim:

 CREATE TABLE pedido_2008 (LIKE pedido INCLUDING ALL);
 ALTER TABLE pedido_2008 INHERIT pedido;


 Bom, aí já é uma questão de gosto... :-P


É um pouco de preciosismo eu sei, mas como dizem *cada louco com sua mania*.

Att,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Blog sobre TI: http://fabriziomello.blogspot.com
 Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento parte 1 - Quando

[Fábio Telles Rodriguez]

Em 10 de janeiro de 2013 10:48, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 2013/1/10 Fábio Telles Rodriguez fabio.tel...@gmail.com
 
 
  Boa, vou atualizar isso. Acho que vale uma conversa aprofundada para
 esse item.

 Sendo uma conversa regada a uma boa cerveja está valendo... :-)


Então, fui tomar uma cerva com o povo aqui no trampo... e dei uma mega
atualizada no texto. Incluí bastante coisa, mas acho que ainda vão mais 2
posts para terminar de cobrir o assunto. Claro, o último post vai ser
aquela função para automatizar tudo... :-)

[]s
-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/
avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

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

[pgbr-geral] Particionamento de tabelas fazer ou não?

[Joel Landim Mourão]

Boa tarde amigos,

Andei lendo sobre o assunto depois de ter participado do PGDAY-SP, mas
alguns documentos dizem que não é recomendável que o particionamento não
traga muitos particionamentos, eu consigo particionar em meses, mas meus
clientes costumam manter os dados por mais de dois anos, ainda é aceitável
que eu tenha este tipo de particionamento?

Outra questão, todos os realtórios gerados são baseado apenas em dia, nunca
em intervalo que intercale um dia com o outro, caso isso aconteça a
apresentação sera separada em dia da mesma forma.

Existem outros relatórios que são materializados em outras tabelas, mas
tudo seguindo o padrão de dias.

Eu tenho condições de ajustar a minha aplicação para que em vez de ter uma
tabela mãe, eu consulte sempre as tabelas particionadas.

Olhando este cenário, é um caminho aceitável e ou até recomendável para
minha aplicação, considerando que esta tabela que será particionada já
chegou a ter 180GB em 2 anos em alguns clientes, e é importante dizer, a
app e o banco estão no mesmo servidor por não ser de nivel critico ou de
muitas conexões, até hoje não mais que 200 conexões (localhost) simultaneas
em nossos maiores clientes.

-- 
Joel Landim Mourã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] Particionamento de tabelas fazer ou não?

[Danilo Silva]

Em 7 de dezembro de 2012 12:19, Joel Landim Mourão jlmou...@gmail.comescreveu:

 Boa tarde amigos,

 Andei lendo sobre o assunto depois de ter participado do PGDAY-SP, mas
 alguns documentos dizem que não é recomendável que o particionamento não
 traga muitos particionamentos, eu consigo particionar em meses, mas meus
 clientes costumam manter os dados por mais de dois anos, ainda é aceitável
 que eu tenha este tipo de particionamento?

 Outra questão, todos os realtórios gerados são baseado apenas em dia,
 nunca em intervalo que intercale um dia com o outro, caso isso aconteça a
 apresentação sera separada em dia da mesma forma.

 Existem outros relatórios que são materializados em outras tabelas, mas
 tudo seguindo o padrão de dias.

 Eu tenho condições de ajustar a minha aplicação para que em vez de ter uma
 tabela mãe, eu consulte sempre as tabelas particionadas.


 Se não me engano, não será necessário efetuar consulta nas tabelas
filhas, uma vez que, quem cuida deste processo é a tabela pai, ou seja,
se você tem um particionamento em meses (JAN, FEV, MAR) e quiser efetuar
uma consulta que traga registros de dois meses por exemplo, o seu select
será na tabela pai e ele irá consultar nas tabelas filhas os registros
que atendem a sua consulta.

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

Re: [pgbr-geral] Particionamento de tabelas fazer ou não?

[Joel Landim Mourão]

Em 7 de dezembro de 2012 12:52, Danilo Silva
danilo.dsg.go...@gmail.comescreveu:

 Em 7 de dezembro de 2012 12:19, Joel Landim Mourão 
 jlmou...@gmail.comescreveu:

 Boa tarde amigos,

 Andei lendo sobre o assunto depois de ter participado do PGDAY-SP, mas
 alguns documentos dizem que não é recomendável que o particionamento não
 traga muitos particionamentos, eu consigo particionar em meses, mas meus
 clientes costumam manter os dados por mais de dois anos, ainda é aceitável
 que eu tenha este tipo de particionamento?

 Outra questão, todos os realtórios gerados são baseado apenas em dia,
 nunca em intervalo que intercale um dia com o outro, caso isso aconteça a
 apresentação sera separada em dia da mesma forma.

 Existem outros relatórios que são materializados em outras tabelas, mas
 tudo seguindo o padrão de dias.

 Eu tenho condições de ajustar a minha aplicação para que em vez de ter
 uma tabela mãe, eu consulte sempre as tabelas particionadas.


 Se não me engano, não será necessário efetuar consulta nas tabelas
 filhas, uma vez que, quem cuida deste processo é a tabela pai, ou seja,
 se você tem um particionamento em meses (JAN, FEV, MAR) e quiser efetuar
 uma consulta que traga registros de dois meses por exemplo, o seu select
 será na tabela pai e ele irá consultar nas tabelas filhas os registros
 que atendem a sua consulta.


Bom como coloquei antes, não tenho esta questão de intercalar os
intervalos, pois a app pode ser moldada de acordo, sendo assim
desnecessário o uso da tabela pai, mesmo que eu tenha um intervalo que
busque em partições diferentes, e desta forma acho que será desnecessário o
uso de uma tabela pai neste cenário.

-- 
Joel Landim Mourã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] Particionamento de tabelas fazer ou não?

[Joel Landim Mourão]

Em 7 de dezembro de 2012 14:34, Matheus de Oliveira 
matioli.math...@gmail.com escreveu:

 2012/12/7 Joel Landim Mourão jlmou...@gmail.com

 Boa tarde amigos,

 Andei lendo sobre o assunto depois de ter participado do PGDAY-SP, mas
 alguns documentos dizem que não é recomendável que o particionamento não
 traga muitos particionamentos,


 Depende. Não é recomendado muitas partições, 100 seria um limite (não
 exato), agora, quanto à número mínimo de partições não vejo nenhuma
 restrição.


  eu consigo particionar em meses, mas meus clientes costumam manter os
 dados por mais de dois anos, ainda é aceitável que eu tenha este tipo de
 particionamento?


 Acredito que dependerá mais da quantidade de informações que tem
 armazenada do que no tempo em que elas permanecem lá. É claro que fazer
 expurgo de partições inteiras é bem mais rápido, é esse o caso?



 Outra questão, todos os realtórios gerados são baseado apenas em dia,
 nunca em intervalo que intercale um dia com o outro, caso isso aconteça a
 apresentação sera separada em dia da mesma forma.


 De qualquer forma, sempre que exibe um dia você iria em uma só partição, e
 não precisaria buscar em várias. Você poderia inclusive particionar por ano
 ou por semestre (ou outro padrão, como intervalos de ID), diminuindo a
 quantidade de partições. Não precisa ser exatamente dia ou mês.



 Existem outros relatórios que são materializados em outras tabelas, mas
 tudo seguindo o padrão de dias.

 Eu tenho condições de ajustar a minha aplicação para que em vez de ter
 uma tabela mãe, eu consulte sempre as tabelas particionadas.


 Para o particionamento do PostgreSQL, na maioria dos casos, não precisa
 mudar nada na aplicação, a não ser que não use a chave da partição nas
 consultas.


Como se trata de uma aplicação distribuida eu terei de moldar o sistema
para que ele seja capaz de criar as proprias partições e toda sua
estrutura, pois não há como ter uma manutenção a cada cliente a cada mês,
por isso a mudança no comportamento do sistema talvez seja mais
interessante apesar de mais arriscado.





 Olhando este cenário, é um caminho aceitável e ou até recomendável para
 minha aplicação, considerando que esta tabela que será particionada já
 chegou a ter 180GB em 2 anos em alguns clientes, e é importante dizer, a
 app e o banco estão no mesmo servidor por não ser de nivel critico ou de
 muitas conexões, até hoje não mais que 200 conexões (localhost) simultaneas
 em nossos maiores clientes.


 Cara, como já disse, vai depender da quantidade de registros dessa tabela
 (do tamanho deles também) e o padrão/modelo de acesso, em muitos casos
 180GB não é considerado assim tão grande.

 Primeiro pergunte-se o porquê de você estar buscando o particionamento.
 Está enfrentando problemas de performance? É para agilizar o expurgo de
 dados? Muitos buracos na tabela?


Sim o objetivo é a performance pois existem alguns relatórios que ficam
extremamente lentos mas quando isolo um numero menor de registros isso já
me da um resultado aceitável e o expurgo de periodos sempre basados em
mêses.



 Atenciosamente,
 --
 Matheus de Oliveira
 Analista de Banco de Dados PostgreSQL
 Dextra Sistemas - MPS.Br nível F!
 www.dextra.com.br/postgres



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




-- 
Joel Landim Mourão
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Particionamento de Tabelas

[Cesar Moraes]

Boa tarde,

Estava estudando particionamento de tabela e me surgiram alguma duvidas.

Para particionar tabelas no Postgres voce deve criar tabelas tabelas
filhas que herdam a estrutura da tabela pai.

E quando vc faz o insert de um registro novo vc precisa ter um Rule ou
Trigger para inserir na tabela correta, certo?
Significa que se eu tiver 20 partições preciso ter 20 triggers.

E quando eu faço um select eu preciso passar a tabela tb? vou precisar
criar mais 20 Rules para fazer o select no local correto?

Agradeço a ajuda

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

Re: [pgbr-geral] Particionamento de Tabelas

[Flavio Henrique Araque Gurgel]

Em 05-07-2012 13:50, Cesar Moraes escreveu:
 Boa tarde,

 Estava estudando particionamento de tabela e me surgiram alguma duvidas.

 Para particionar tabelas no Postgres voce deve criar tabelas tabelas
 filhas que herdam a estrutura da tabela pai.

 E quando vc faz o insert de um registro novo vc precisa ter um Rule ou
 Trigger para inserir na tabela correta, certo?

Certo.

 Significa que se eu tiver 20 partições preciso ter 20 triggers.

Não.
Você precisa de apenas um gatilho na tabela pai cuja lógica escolhe a 
tabela filha adequada.

 E quando eu faço um select eu preciso passar a tabela tb? vou precisar
 criar mais 20 Rules para fazer o select no local correto?

Não. O sistema de herança cuida disso pra você.
As operações SELECT, UPDATE e DELETE são feitas sobre a tabela pai. Os 
resultados automaticamente virão das tabelas filhas. Você não precisa se 
preocupar com nada nestes casos.

Apenas a operação de INSERT precisa de um gatilho ou regra na tabela 
pai para escolher para qual filha o dado vai. Na minha experiência, 
gatilhos são muito mais rápidos que regras.

[]s

Flavio Henrique A. Gurgel
Consultor e Instrutor 4Linux
Tel: +55-11-2125-4747
www.4linux.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento de Tabelas

[Matheus de Oliveira]

  E quando eu faço um select eu preciso passar a tabela tb? vou precisar
  criar mais 20 Rules para fazer o select no local correto?

 Não. O sistema de herança cuida disso pra você.
 As operações SELECT, UPDATE e DELETE são feitas sobre a tabela pai. Os
 resultados automaticamente virão das tabelas filhas. Você não precisa se
 preocupar com nada nestes casos.

 Apenas a operação de INSERT precisa de um gatilho ou regra na tabela
 pai para escolher para qual filha o dado vai. Na minha experiência,
 gatilhos são muito mais rápidos que regras.


Só complementando, tem que lembrar de criar constraints CHECKs nas tabelas
filhas (para restringir as partições) e manter o parâmetro constraint_check
como on, se não o particionamento não fará muito sentido, ou seja, ele fará
um UNION ALL em todas as tabelas.

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

Re: [pgbr-geral] Particionamento de Tabelas

[Fabrízio de Royes Mello]

Em 5 de julho de 2012 14:31, Matheus de Oliveira
matioli.math...@gmail.comescreveu:


 Só complementando, tem que lembrar de criar constraints CHECKs nas
 tabelas filhas (para restringir as partições) e manter o parâmetro
 constraint_check como on, se não o particionamento não fará muito sentido,
 ou seja, ele fará um UNION ALL em todas as tabelas.


Creio que vc quis falar sobre a GUC constraint_exclusion [1].

[1]
http://www.postgresql.org/docs/9.1/static/runtime-config-query.html#GUC-CONSTRAINT-EXCLUSION

-- 
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Blog sobre TI: http://fabriziomello.blogspot.com
 Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento de Tabelas

[Matheus de Oliveira]

 Só complementando, tem que lembrar de criar constraints CHECKs nas tabelas
 filhas (para restringir as partições) e manter o parâmetro constraint_check
 como on, se não o particionamento não fará muito sentido, ou seja, ele fará
 um UNION ALL em todas as tabelas.


 Creio que vc quis falar sobre a GUC constraint_exclusion [1].


Ops... Tô com memória corrompinda aqui!

Tem razão, é constraint_exclusion.

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

Re: [pgbr-geral] Particionamento de Tabelas

[Targino Silveira]

Um outro detalhe importante é a excução de queries:

select * from tabela_pai //Será executado na tabela pai e filhas
select * from only tabela_pai //Será executado somente na tabela pai
select * from only tabela_filha1 //Será realizado somente na tabela filha 1

A mesma regra segue para UPDATE e DELETE.

Abraços,

Em 5 de julho de 2012 15:46, Matheus de Oliveira
matioli.math...@gmail.comescreveu:

 Só complementando, tem que lembrar de criar constraints CHECKs nas tabelas
 filhas (para restringir as partições) e manter o parâmetro constraint_check
 como on, se não o particionamento não fará muito sentido, ou seja, ele fará
 um UNION ALL em todas as tabelas.


 Creio que vc quis falar sobre a GUC constraint_exclusion [1].


 Ops... Tô com memória corrompinda aqui!

 Tem razão, é constraint_exclusion.

 Atenciosamente,
 --
 Matheus de Oliveira


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




-- 
Targino Silveira
+55-85-8626-7297
www.twitter.com/targinosilveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento de Tabelas

[Cesar Moraes]

Opa muito obrigado pela ajuda de todos.

Bom a Check é para garantir que os dados não sejam gravados no lugar errado
e o constraint_exclusion é para não fazer o UNION, é isso mesmo?

Mas como o Targino falou.
Se eu tiver uma tabela de 10 MI de registros dividida em 10 partições.
E fizer um select na tabela pai ele vai ler os 10 MI de registros ou vai
achar a tabela filha e ler somente 1 MI?

At
Cesar Moraes

2012/7/5 Targino Silveira targinosilve...@gmail.com

 Um outro detalhe importante é a excução de queries:

 select * from tabela_pai //Será executado na tabela pai e filhas
 select * from only tabela_pai //Será executado somente na tabela pai
 select * from only tabela_filha1 //Será realizado somente na tabela filha 1

 A mesma regra segue para UPDATE e DELETE.

 Abraços,

 Em 5 de julho de 2012 15:46, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:

  Só complementando, tem que lembrar de criar constraints CHECKs nas
 tabelas filhas (para restringir as partições) e manter o parâmetro
 constraint_check como on, se não o particionamento não fará muito sentido,
 ou seja, ele fará um UNION ALL em todas as tabelas.


 Creio que vc quis falar sobre a GUC constraint_exclusion [1].


 Ops... Tô com memória corrompinda aqui!

 Tem razão, é constraint_exclusion.

 Atenciosamente,
 --
 Matheus de Oliveira


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




 --
 Targino Silveira
 +55-85-8626-7297
 www.twitter.com/targinosilveira

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


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

Re: [pgbr-geral] Particionamento de Tabelas

[Targino Silveira]

Se você usar FROM ONLY somente na tabela(s) especificadas.

Um detalhe o ONLY é somente para a tabela Pai, nas tabelas filhas você não
tem obrigatoriedade de uso, somente se quiser.

Abraços,

Em 5 de julho de 2012 17:21, Cesar Moraes cesar.cs...@gmail.com escreveu:

 Opa muito obrigado pela ajuda de todos.

 Bom a Check é para garantir que os dados não sejam gravados no lugar
 errado e o constraint_exclusion é para não fazer o UNION, é isso mesmo?

 Mas como o Targino falou.
 Se eu tiver uma tabela de 10 MI de registros dividida em 10 partições.
 E fizer um select na tabela pai ele vai ler os 10 MI de registros ou vai
 achar a tabela filha e ler somente 1 MI?

 At
 Cesar Moraes


 2012/7/5 Targino Silveira targinosilve...@gmail.com

 Um outro detalhe importante é a excução de queries:

 select * from tabela_pai //Será executado na tabela pai e filhas
 select * from only tabela_pai //Será executado somente na tabela pai
 select * from only tabela_filha1 //Será realizado somente na tabela filha
 1

 A mesma regra segue para UPDATE e DELETE.

 Abraços,

 Em 5 de julho de 2012 15:46, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:

  Só complementando, tem que lembrar de criar constraints CHECKs nas
 tabelas filhas (para restringir as partições) e manter o parâmetro
 constraint_check como on, se não o particionamento não fará muito sentido,
 ou seja, ele fará um UNION ALL em todas as tabelas.


 Creio que vc quis falar sobre a GUC constraint_exclusion [1].


 Ops... Tô com memória corrompinda aqui!

 Tem razão, é constraint_exclusion.

 Atenciosamente,
 --
 Matheus de Oliveira


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




 --
 Targino Silveira
 +55-85-8626-7297
 www.twitter.com/targinosilveira

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



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




-- 
Targino Silveira
+55-85-8626-7297
www.twitter.com/targinosilveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento de Tabelas

[Fábio Gibon]

Se o teu select tiver uma clausula where que apenas uma partição atenda
então o banco vai ler apenas os dados desta partição.

* independente de ONLY.

sds
Fabio

Em 5 de julho de 2012 17:34, Targino Silveira
targinosilve...@gmail.comescreveu:

 Se você usar FROM ONLY somente na tabela(s) especificadas.

 Um detalhe o ONLY é somente para a tabela Pai, nas tabelas filhas você não
 tem obrigatoriedade de uso, somente se quiser.

 Abraços,

 Em 5 de julho de 2012 17:21, Cesar Moraes cesar.cs...@gmail.comescreveu:

 Opa muito obrigado pela ajuda de todos.

 Bom a Check é para garantir que os dados não sejam gravados no lugar
 errado e o constraint_exclusion é para não fazer o UNION, é isso mesmo?

 Mas como o Targino falou.
 Se eu tiver uma tabela de 10 MI de registros dividida em 10 partições.
 E fizer um select na tabela pai ele vai ler os 10 MI de registros ou vai
 achar a tabela filha e ler somente 1 MI?

 At
 Cesar Moraes


 2012/7/5 Targino Silveira targinosilve...@gmail.com

 Um outro detalhe importante é a excução de queries:

 select * from tabela_pai //Será executado na tabela pai e filhas
 select * from only tabela_pai //Será executado somente na tabela pai
 select * from only tabela_filha1 //Será realizado somente na tabela
 filha 1

 A mesma regra segue para UPDATE e DELETE.

 Abraços,

 Em 5 de julho de 2012 15:46, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:

  Só complementando, tem que lembrar de criar constraints CHECKs nas
 tabelas filhas (para restringir as partições) e manter o parâmetro
 constraint_check como on, se não o particionamento não fará muito 
 sentido,
 ou seja, ele fará um UNION ALL em todas as tabelas.


 Creio que vc quis falar sobre a GUC constraint_exclusion [1].


 Ops... Tô com memória corrompinda aqui!

 Tem razão, é constraint_exclusion.

 Atenciosamente,
 --
 Matheus de Oliveira


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




 --
 Targino Silveira
 +55-85-8626-7297
 www.twitter.com/targinosilveira

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



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




 --
 Targino Silveira
 +55-85-8626-7297
 www.twitter.com/targinosilveira

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




-- 
sds

Fábio Henrique Gibon
Comex System Consultoria
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento de Tabelas

[Euler Taveira]

On 05-07-2012 17:21, Cesar Moraes wrote:
 Bom a Check é para garantir que os dados não sejam gravados no lugar errado e
 o constraint_exclusion é para não fazer o UNION, é isso mesmo?
 
± ... A restrição de verificação (aka CHECK) também serve para o planejador
adivinhar quais as partições ele deve considerar se constraint_exclusion
estiver habilitado (on / partition).

 Mas como o Targino falou.
 Se eu tiver uma tabela de 10 MI de registros dividida em 10 partições.
 E fizer um select na tabela pai ele vai ler os 10 MI de registros ou vai achar
 a tabela filha e ler somente 1 MI?
 
Somente as tabelas filho cuja condição da consulta casa com a condição CHECK
das tabelas filho. Eu lhe aconselho fortemente ler o capítulo sobre
particionamento [1].


[1] http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html


-- 
   Euler Taveira de Oliveira - Timbira   http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento de Tabelas

[Euler Taveira]

On 05-07-2012 17:21, Cesar Moraes wrote:
 Bom a Check é para garantir que os dados não sejam gravados no lugar errado e
 o constraint_exclusion é para não fazer o UNION, é isso mesmo?
 
± ... A restrição de verificação (aka CHECK) também serve para o planejador
adivinhar quais as partições ele deve considerar se constraint_exclusion
estiver habilitado (on / partition).

 Mas como o Targino falou.
 Se eu tiver uma tabela de 10 MI de registros dividida em 10 partições.
 E fizer um select na tabela pai ele vai ler os 10 MI de registros ou vai achar
 a tabela filha e ler somente 1 MI?
 
Somente as tabelas filho cuja condição da consulta casa com a condição CHECK
das tabelas filho. Eu lhe aconselho fortemente ler o capítulo sobre
particionamento [1].


[1] http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html


-- 
   Euler Taveira de Oliveira - Timbira   http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Particionamento de HD

[Roney Fraga Soouza]

Caros,

Utilizo Ubuntu (xfce) em um notebook com HD particionado em /sda1 49 GB 
e /sda3 409 GB. Utilizo essa estrutura para deixar /home na partição 
maior, e quando for atualizar (reinstalar) o sistema operacional não 
precisar mexer em /home. Contudo, agora estou com problema pq preciso 
colocar muitos arquivos .csv no postgresql, acedito que será no total 
uns 70 GB, o que não será suportado em /sda1 que tem apenas 49 GB. É 
possível que o postgresql armazene seus arquivos em /sda3 que tem 409GB?

Obs.: Meu uso do postgresql é apenas para consulta ou para ligação com o 
software R, portanto não tenho necessidade nenhum tipo de acesso via 
internet ou algo parecido.

Atenciosamente

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

Re: [pgbr-geral] Particionamento de HD

[Bruno Silva]

Você pode criar uma tablespace!
Crie uma pasta no home, dê permissão ao usuário do serviço do banco -
geralmente o.usuario é postgres - e crie a tablespace dentro dela.
Em 19/03/2012 20:47, Roney Fraga Soouza roneyfr...@gmail.com escreveu:

 Caros,

 Utilizo Ubuntu (xfce) em um notebook com HD particionado em /sda1 49 GB
 e /sda3 409 GB. Utilizo essa estrutura para deixar /home na partição
 maior, e quando for atualizar (reinstalar) o sistema operacional não
 precisar mexer em /home. Contudo, agora estou com problema pq preciso
 colocar muitos arquivos .csv no postgresql, acedito que será no total
 uns 70 GB, o que não será suportado em /sda1 que tem apenas 49 GB. É
 possível que o postgresql armazene seus arquivos em /sda3 que tem 409GB?

 Obs.: Meu uso do postgresql é apenas para consulta ou para ligação com o
 software R, portanto não tenho necessidade nenhum tipo de acesso via
 internet ou algo parecido.

 Atenciosamente

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

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

Re: [pgbr-geral] Particionamento de HD

[Leandro Guimarães Faria Corce DUTRA]

Le 2012-M-19  20h47, Roney Fraga Soouza a écrit :

 É possível que o postgresql armazene seus arquivos em /sda3 que tem
 409GB?

O que eu gosto de fazer é separar /srv e botar os dados em /srv/pg.




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

[pgbr-geral] Particionamento de tabelas

[Danilo Silva]

Pessoal,

Alguém sabe onde posso encontrar documentação ou tutorial sobre
particionamento de tabelas, de preferência em português?

Agradeço desde já e obrigado a todos

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

Re: [pgbr-geral] Particionamento de tabelas

[Rodrigo Della Justina]

Danilo,

Tem um exemplo bem legal sobre particionamento de tabelas no PostgreSQL...

http://keniamilene.wordpress.com/2008/05/26/particionamento-de-tabelas-no-postgresql/


É muito utilizado particionamento de tabelas em Armazém de dados (Data
WareHouse)


Atenciosamente
Rodrigo


Em 11 de janeiro de 2012 00:05, Danilo Silva
danilo.dsg.go...@gmail.comescreveu:

 Pessoal,

 Alguém sabe onde posso encontrar documentação ou tutorial sobre
 particionamento de tabelas, de preferência em português?

 Agradeço desde já e obrigado a todos

 Abs Danilo

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




-- 
*Atenciosamente*
*
*
*Rodrigo Della Justina*
*rodrigodellajust...@gmail.com*
*rodrigodellajust...@ciss.com.br*
Telp: 55-46-8801-6165

*IBM DB2 Certified Database Academic*
*
*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Particionamento de tabelas row_count retona ZERO

[Hugo Bastos Bucker]

Boa Tarde a todos,

Álguem já se deparou com o problema de ao particionar uma tabela o
ROW_COUNT retornar ZERO?
Será que tem como fazer a trigger retornar a quantidade de registros que
foram inseridos, pois ao usar o RETURN NULL na trigger o PG não
contabiliza a linha.
Como não tenho controle sobre a aplicação estou com receio de que ela faça
algum teste sobre a quantidade de registros incluídos.

Abraços,

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

Re: [pgbr-geral] Particionamento de tabelas row_count retona ZERO

[Flavio Henrique Araque Gurgel]

 Álguem já se deparou com o problema de ao particionar uma tabela o ROW_COUNT
 retornar ZERO?

Eu.

 Será que tem como fazer a trigger retornar a quantidade de registros que
 foram inseridos, pois ao usar o RETURN NULL na trigger o PG não
 contabiliza a linha.

Não, não tem como.

 Como não tenho controle sobre a aplicação estou com receio de que ela faça
 algum teste sobre a quantidade de registros incluídos.

Sua aplicação não deveria fazer nenhum check aí, pois se o PostgreSQL
não retornar erros, quer dizer que o INSERT foi feito com sucesso,
exatamente como foi solicitado pela aplicação.

Já passei por isso em aplicações Java com Hibernate. É possível
configurar o Hibernate pra não fazer essa verificação, que é
totalmente desprezível do ponto de vista do banco de dados.

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

Re: [pgbr-geral] Particionamento de tabelas row_count retona ZERO

[Hugo Bastos Bucker]

Valeu Flavio, eu imaginei pelas pesquisas que fiz e testes... mas vc sabe,
sempre é bom ter uma segunda opnião.

Abraços,

Hugo.

Em 15 de dezembro de 2011 15:15, Flavio Henrique Araque Gurgel 
fha...@gmail.com escreveu:

  Álguem já se deparou com o problema de ao particionar uma tabela o
 ROW_COUNT
  retornar ZERO?

 Eu.

  Será que tem como fazer a trigger retornar a quantidade de registros que
  foram inseridos, pois ao usar o RETURN NULL na trigger o PG não
  contabiliza a linha.

 Não, não tem como.

  Como não tenho controle sobre a aplicação estou com receio de que ela
 faça
  algum teste sobre a quantidade de registros incluídos.

 Sua aplicação não deveria fazer nenhum check aí, pois se o PostgreSQL
 não retornar erros, quer dizer que o INSERT foi feito com sucesso,
 exatamente como foi solicitado pela aplicação.

 Já passei por isso em aplicações Java com Hibernate. É possível
 configurar o Hibernate pra não fazer essa verificação, que é
 totalmente desprezível do ponto de vista do banco de dados.

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

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

[pgbr-geral] Particionamento x Herança

[letgaude]

Boa Tarde,

Em todos os foruns sobre particionamento, é dito que a implementação desta é
feita através de herança. Que precisa criar uma trigger ou role pra
redirecionar os registros para as tabelas filhas e etc. No entanto, com a
herança, os dados acabam ficando nas duas tabelas, gerando redundância. É
assim mesmo ? Acho que vou particionar sem herança, pois assim não gero
duplicação de informações.

Grata,

Letícia
-- 
View this message in context: 
http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28030200.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

Re: [pgbr-geral] Particionamento x Herança

[JotaComm]

Olá,

Em 25 de março de 2010 12:07, letgaude letga...@gmail.com escreveu:


 Boa Tarde,

 Em todos os foruns sobre particionamento, é dito que a implementação desta
 é
 feita através de herança. Que precisa criar uma trigger ou role pra
 redirecionar os registros para as tabelas filhas e etc. No entanto, com a
 herança, os dados acabam ficando nas duas tabelas, gerando redundância. É
 assim mesmo ? Acho que vou particionar sem herança, pois assim não gero
 duplicação de informações.


Sim, é por herança. Você precisa de uma trigger ou rule e não role.

Não vejo como ficarem dados duplicados, a menos que a trigger ou a rule
esteja implementa de forma incorreta.

Veja mais informações em:
http://www.postgresql.org/docs/8.4/interactive/ddl-partitioning.html



 Grata,

 Letícia
 --
 View this message in context:
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28030200.html
 Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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




Atenciosamente

-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento x Herança

[letgaude]

Desculpe o ROLE. Foi falta de atenção mesmo.

Mas, voltando ao assunto. Eu ja tinha visto esse artigo e foi exatamente o
exemplo q eu usei pra testar. E gerou dados na tabela measurement e na
measurement_y2006m02, por exemplo. 

Mas ao criar as tabelas sem heranca isso nao aconteceu. 



JotaComm wrote:
 
 Olá,
 
 Em 25 de março de 2010 12:07, letgaude letga...@gmail.com escreveu:
 

 Boa Tarde,

 Em todos os foruns sobre particionamento, é dito que a implementação
 desta
 é
 feita através de herança. Que precisa criar uma trigger ou role pra
 redirecionar os registros para as tabelas filhas e etc. No entanto, com a
 herança, os dados acabam ficando nas duas tabelas, gerando redundância. É
 assim mesmo ? Acho que vou particionar sem herança, pois assim não gero
 duplicação de informações.

 
 Sim, é por herança. Você precisa de uma trigger ou rule e não role.
 
 Não vejo como ficarem dados duplicados, a menos que a trigger ou a rule
 esteja implementa de forma incorreta.
 
 Veja mais informações em:
 http://www.postgresql.org/docs/8.4/interactive/ddl-partitioning.html
 
 

 Grata,

 Letícia
 --
 View this message in context:
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28030200.html
 Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

 
 
 
 Atenciosamente
 
 -- 
 JotaComm
 http://jotacomm.wordpress.com
 
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 

-- 
View this message in context: 
http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031730.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

Re: [pgbr-geral] Particionamento x Herança

[JotaComm]

Olá,

Em 25 de março de 2010 13:50, letgaude letga...@gmail.com escreveu:


 Desculpe o ROLE. Foi falta de atenção mesmo.

 Mas, voltando ao assunto. Eu ja tinha visto esse artigo e foi exatamente o
 exemplo q eu usei pra testar. E gerou dados na tabela measurement e na
 measurement_y2006m02, por exemplo.




 Mas ao criar as tabelas sem heranca isso nao aconteceu.


Acho que tem alguma coisa errada na sua implementação. Como está o RETURN da
sua função? Está com RETURN NULL ou RETURN NEW?




 JotaComm wrote:
 
  Olá,
 
  Em 25 de março de 2010 12:07, letgaude letga...@gmail.com escreveu:
 
 
  Boa Tarde,
 
  Em todos os foruns sobre particionamento, é dito que a implementação
  desta
  é
  feita através de herança. Que precisa criar uma trigger ou role pra
  redirecionar os registros para as tabelas filhas e etc. No entanto, com
 a
  herança, os dados acabam ficando nas duas tabelas, gerando redundância.
 É
  assim mesmo ? Acho que vou particionar sem herança, pois assim não gero
  duplicação de informações.
 
 
  Sim, é por herança. Você precisa de uma trigger ou rule e não role.
 
  Não vejo como ficarem dados duplicados, a menos que a trigger ou a rule
  esteja implementa de forma incorreta.
 
  Veja mais informações em:
  http://www.postgresql.org/docs/8.4/interactive/ddl-partitioning.html
 
 
 
  Grata,
 
  Letícia
  --
  View this message in context:
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28030200.html
  Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
 
  Atenciosamente
 
  --
  JotaComm
  http://jotacomm.wordpress.com
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 

 --
 View this message in context:
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031730.html
 Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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




-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento x Herança

[letgaude]

Esta exatamente como no exemplo do link q você passou:

--- TRIGGER  
CREATE TRIGGER insert_measurement_trigger
BEFORE INSERT ON measurement
FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();

--- FUNCTION  
CREATE OR REPLACE FUNCTION measurement_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
IF ( NEW.logdate = DATE '2006-02-01' AND
 NEW.logdate  DATE '2006-03-01' ) THEN
INSERT INTO measurement_y2006m02 VALUES (NEW.*);
ELSE
RAISE EXCEPTION 'Date out of range.  Fix the
measurement_insert_trigger() function!';
END IF;
RETURN NULL;
END;






JotaComm wrote:
 
 Olá,
 
 Em 25 de março de 2010 13:50, letgaude letga...@gmail.com escreveu:
 

 Desculpe o ROLE. Foi falta de atenção mesmo.

 Mas, voltando ao assunto. Eu ja tinha visto esse artigo e foi exatamente
 o
 exemplo q eu usei pra testar. E gerou dados na tabela measurement e na
 measurement_y2006m02, por exemplo.

 
 

 Mas ao criar as tabelas sem heranca isso nao aconteceu.

 
 Acho que tem alguma coisa errada na sua implementação. Como está o RETURN
 da
 sua função? Está com RETURN NULL ou RETURN NEW?
 



 JotaComm wrote:
 
  Olá,
 
  Em 25 de março de 2010 12:07, letgaude letga...@gmail.com escreveu:
 
 
  Boa Tarde,
 
  Em todos os foruns sobre particionamento, é dito que a implementação
  desta
  é
  feita através de herança. Que precisa criar uma trigger ou role pra
  redirecionar os registros para as tabelas filhas e etc. No entanto,
 com
 a
  herança, os dados acabam ficando nas duas tabelas, gerando
 redundância.
 É
  assim mesmo ? Acho que vou particionar sem herança, pois assim não
 gero
  duplicação de informações.
 
 
  Sim, é por herança. Você precisa de uma trigger ou rule e não role.
 
  Não vejo como ficarem dados duplicados, a menos que a trigger ou a rule
  esteja implementa de forma incorreta.
 
  Veja mais informações em:
  http://www.postgresql.org/docs/8.4/interactive/ddl-partitioning.html
 
 
 
  Grata,
 
  Letícia
  --
  View this message in context:
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28030200.html
  Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
 
  Atenciosamente
 
  --
  JotaComm
  http://jotacomm.wordpress.com
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 

 --
 View this message in context:
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031730.html
 Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

 
 
 
 -- 
 JotaComm
 http://jotacomm.wordpress.com
 
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 

-- 
View this message in context: 
http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031875.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

Re: [pgbr-geral] Particionamento x Herança

[JotaComm]

Olá,

Em 25 de março de 2010 13:59, letgaude letga...@gmail.com escreveu:


 Esta exatamente como no exemplo do link q você passou:

 --- TRIGGER 
 CREATE TRIGGER insert_measurement_trigger
BEFORE INSERT ON measurement
FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();

 --- FUNCTION 
 CREATE OR REPLACE FUNCTION measurement_insert_trigger()
 RETURNS TRIGGER AS $$
 BEGIN
IF ( NEW.logdate = DATE '2006-02-01' AND
 NEW.logdate  DATE '2006-03-01' ) THEN
INSERT INTO measurement_y2006m02 VALUES (NEW.*);
ELSE
RAISE EXCEPTION 'Date out of range.  Fix the
 measurement_insert_trigger() function!';
END IF;
RETURN NULL;
 END;


 Pode me mostrar um exemplo de que os dados estão duplicados?


Como você fez o SELECT na tabela pai e na tabela filha. Você usou a
clausula ONLY na tabela pai quando fez o SELECT?




 JotaComm wrote:
 
  Olá,
 
  Em 25 de março de 2010 13:50, letgaude letga...@gmail.com escreveu:
 
 
  Desculpe o ROLE. Foi falta de atenção mesmo.
 
  Mas, voltando ao assunto. Eu ja tinha visto esse artigo e foi exatamente
  o
  exemplo q eu usei pra testar. E gerou dados na tabela measurement e na
  measurement_y2006m02, por exemplo.
 
 
 
 
  Mas ao criar as tabelas sem heranca isso nao aconteceu.
 
 
  Acho que tem alguma coisa errada na sua implementação. Como está o RETURN
  da
  sua função? Está com RETURN NULL ou RETURN NEW?
 
 
 
 
  JotaComm wrote:
  
   Olá,
  
   Em 25 de março de 2010 12:07, letgaude letga...@gmail.com escreveu:
  
  
   Boa Tarde,
  
   Em todos os foruns sobre particionamento, é dito que a implementação
   desta
   é
   feita através de herança. Que precisa criar uma trigger ou role pra
   redirecionar os registros para as tabelas filhas e etc. No entanto,
  com
  a
   herança, os dados acabam ficando nas duas tabelas, gerando
  redundância.
  É
   assim mesmo ? Acho que vou particionar sem herança, pois assim não
  gero
   duplicação de informações.
  
  
   Sim, é por herança. Você precisa de uma trigger ou rule e não role.
  
   Não vejo como ficarem dados duplicados, a menos que a trigger ou a
 rule
   esteja implementa de forma incorreta.
  
   Veja mais informações em:
   http://www.postgresql.org/docs/8.4/interactive/ddl-partitioning.html
  
  
  
   Grata,
  
   Letícia
   --
   View this message in context:
  
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28030200.html
   Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
  
   ___
   pgbr-geral mailing list
   pgbr-geral@listas.postgresql.org.br
   https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  
  
  
  
   Atenciosamente
  
   --
   JotaComm
   http://jotacomm.wordpress.com
  
   ___
   pgbr-geral mailing list
   pgbr-geral@listas.postgresql.org.br
   https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  
  
 
  --
  View this message in context:
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031730.html
  Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
 
  --
  JotaComm
  http://jotacomm.wordpress.com
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 

 --
 View this message in context:
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031875.html
 Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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




-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento x Herança

[JotaComm]

Olá,

Em 25 de março de 2010 14:09, letgaude letga...@gmail.com escreveu:


 Bom, eu fiz insert na tabela pai, ex:

 insert into measurement
 values
 (1, '2006-02-04', 1, 1);

 Depois simplesmente dei select nas duas tabelas e vi q o mesmo dado estava
 na tabela measurement e
 e na measurement_y2006m02.


Na verdade não. Quando você faz um SELECT na tabela pai ele também busca os
dados na tabela filha. Se você quer ver somente os dados do pai você deve
fazer:

SELECT * FROM ONLY pai;


 Mas essa seria a função da trigger/rule: antes de inserir o registro na
 tabela pai verificar a data e inserir so na filha.

 Quem deleta o dado da tabela pai ? Tem alguma configuração ? Outra trigger
 ?


 Obrigada.






 JotaComm wrote:
 
  Olá,
 
  Em 25 de março de 2010 13:59, letgaude letga...@gmail.com escreveu:
 
 
  Esta exatamente como no exemplo do link q você passou:
 
  --- TRIGGER 
  CREATE TRIGGER insert_measurement_trigger
 BEFORE INSERT ON measurement
 FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();
 
  --- FUNCTION 
  CREATE OR REPLACE FUNCTION measurement_insert_trigger()
  RETURNS TRIGGER AS $$
  BEGIN
 IF ( NEW.logdate = DATE '2006-02-01' AND
  NEW.logdate  DATE '2006-03-01' ) THEN
 INSERT INTO measurement_y2006m02 VALUES (NEW.*);
 ELSE
 RAISE EXCEPTION 'Date out of range.  Fix the
  measurement_insert_trigger() function!';
 END IF;
 RETURN NULL;
  END;
 
 
  Pode me mostrar um exemplo de que os dados estão duplicados?
 
 
  Como você fez o SELECT na tabela pai e na tabela filha. Você usou a
  clausula ONLY na tabela pai quando fez o SELECT?
 
 
 
 
  JotaComm wrote:
  
   Olá,
  
   Em 25 de março de 2010 13:50, letgaude letga...@gmail.com escreveu:
  
  
   Desculpe o ROLE. Foi falta de atenção mesmo.
  
   Mas, voltando ao assunto. Eu ja tinha visto esse artigo e foi
  exatamente
   o
   exemplo q eu usei pra testar. E gerou dados na tabela measurement e
 na
   measurement_y2006m02, por exemplo.
  
  
  
  
   Mas ao criar as tabelas sem heranca isso nao aconteceu.
  
  
   Acho que tem alguma coisa errada na sua implementação. Como está o
  RETURN
   da
   sua função? Está com RETURN NULL ou RETURN NEW?
  
  
  
  
   JotaComm wrote:
   
Olá,
   
Em 25 de março de 2010 12:07, letgaude letga...@gmail.com
  escreveu:
   
   
Boa Tarde,
   
Em todos os foruns sobre particionamento, é dito que a
  implementação
desta
é
feita através de herança. Que precisa criar uma trigger ou role
 pra
redirecionar os registros para as tabelas filhas e etc. No
 entanto,
   com
   a
herança, os dados acabam ficando nas duas tabelas, gerando
   redundância.
   É
assim mesmo ? Acho que vou particionar sem herança, pois assim não
   gero
duplicação de informações.
   
   
Sim, é por herança. Você precisa de uma trigger ou rule e não role.
   
Não vejo como ficarem dados duplicados, a menos que a trigger ou a
  rule
esteja implementa de forma incorreta.
   
Veja mais informações em:
   
 http://www.postgresql.org/docs/8.4/interactive/ddl-partitioning.html
   
   
   
Grata,
   
Letícia
--
View this message in context:
   
  
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28030200.html
Sent from the PostgreSQL - Brasil mailing list archive at
  Nabble.com.
   
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
   
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
   
   
   
   
Atenciosamente
   
--
JotaComm
http://jotacomm.wordpress.com
   
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
   
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
   
   
  
   --
   View this message in context:
  
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031730.html
   Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
  
   ___
   pgbr-geral mailing list
   pgbr-geral@listas.postgresql.org.br
   https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  
  
  
  
   --
   JotaComm
   http://jotacomm.wordpress.com
  
   ___
   pgbr-geral mailing list
   pgbr-geral@listas.postgresql.org.br
   https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  
  
 
  --
  View this message in context:
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031875.html
  Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
 
  --
  JotaComm
  http://jotacomm.wordpress.com
 
  

Re: [pgbr-geral] Particionamento x Herança

[letgaude]

Que massa !! Não vi esse detalhe em nenhum dos artigos que eu li. 
Mais uma pergunta: é indicado criar um tablespace para cada partição ? E os
indices ? Devem ser particionados também ?

Obrigada !

Letícia



JotaComm wrote:
 
 Olá,
 
 Em 25 de março de 2010 14:09, letgaude letga...@gmail.com escreveu:
 

 Bom, eu fiz insert na tabela pai, ex:

 insert into measurement
 values
 (1, '2006-02-04', 1, 1);

 Depois simplesmente dei select nas duas tabelas e vi q o mesmo dado
 estava
 na tabela measurement e
 e na measurement_y2006m02.

 
 Na verdade não. Quando você faz um SELECT na tabela pai ele também busca
 os
 dados na tabela filha. Se você quer ver somente os dados do pai você deve
 fazer:
 
 SELECT * FROM ONLY pai;
 

 Mas essa seria a função da trigger/rule: antes de inserir o registro na
 tabela pai verificar a data e inserir so na filha.

 Quem deleta o dado da tabela pai ? Tem alguma configuração ? Outra
 trigger
 ?


 Obrigada.






 JotaComm wrote:
 
  Olá,
 
  Em 25 de março de 2010 13:59, letgaude letga...@gmail.com escreveu:
 
 
  Esta exatamente como no exemplo do link q você passou:
 
  --- TRIGGER 
  CREATE TRIGGER insert_measurement_trigger
 BEFORE INSERT ON measurement
 FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();
 
  --- FUNCTION 
  CREATE OR REPLACE FUNCTION measurement_insert_trigger()
  RETURNS TRIGGER AS $$
  BEGIN
 IF ( NEW.logdate = DATE '2006-02-01' AND
  NEW.logdate  DATE '2006-03-01' ) THEN
 INSERT INTO measurement_y2006m02 VALUES (NEW.*);
 ELSE
 RAISE EXCEPTION 'Date out of range.  Fix the
  measurement_insert_trigger() function!';
 END IF;
 RETURN NULL;
  END;
 
 
  Pode me mostrar um exemplo de que os dados estão duplicados?
 
 
  Como você fez o SELECT na tabela pai e na tabela filha. Você usou a
  clausula ONLY na tabela pai quando fez o SELECT?
 
 
 
 
  JotaComm wrote:
  
   Olá,
  
   Em 25 de março de 2010 13:50, letgaude letga...@gmail.com
 escreveu:
  
  
   Desculpe o ROLE. Foi falta de atenção mesmo.
  
   Mas, voltando ao assunto. Eu ja tinha visto esse artigo e foi
  exatamente
   o
   exemplo q eu usei pra testar. E gerou dados na tabela measurement e
 na
   measurement_y2006m02, por exemplo.
  
  
  
  
   Mas ao criar as tabelas sem heranca isso nao aconteceu.
  
  
   Acho que tem alguma coisa errada na sua implementação. Como está o
  RETURN
   da
   sua função? Está com RETURN NULL ou RETURN NEW?
  
  
  
  
   JotaComm wrote:
   
Olá,
   
Em 25 de março de 2010 12:07, letgaude letga...@gmail.com
  escreveu:
   
   
Boa Tarde,
   
Em todos os foruns sobre particionamento, é dito que a
  implementação
desta
é
feita através de herança. Que precisa criar uma trigger ou role
 pra
redirecionar os registros para as tabelas filhas e etc. No
 entanto,
   com
   a
herança, os dados acabam ficando nas duas tabelas, gerando
   redundância.
   É
assim mesmo ? Acho que vou particionar sem herança, pois assim
 não
   gero
duplicação de informações.
   
   
Sim, é por herança. Você precisa de uma trigger ou rule e não
 role.
   
Não vejo como ficarem dados duplicados, a menos que a trigger ou
 a
  rule
esteja implementa de forma incorreta.
   
Veja mais informações em:
   
 http://www.postgresql.org/docs/8.4/interactive/ddl-partitioning.html
   
   
   
Grata,
   
Letícia
--
View this message in context:
   
  
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28030200.html
Sent from the PostgreSQL - Brasil mailing list archive at
  Nabble.com.
   
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
   
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
   
   
   
   
Atenciosamente
   
--
JotaComm
http://jotacomm.wordpress.com
   
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
   
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
   
   
  
   --
   View this message in context:
  
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031730.html
   Sent from the PostgreSQL - Brasil mailing list archive at
 Nabble.com.
  
   ___
   pgbr-geral mailing list
   pgbr-geral@listas.postgresql.org.br
  
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  
  
  
  
   --
   JotaComm
   http://jotacomm.wordpress.com
  
   ___
   pgbr-geral mailing list
   pgbr-geral@listas.postgresql.org.br
   https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  
  
 
  --
  View this message in context:
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031875.html
  Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
 
  

Re: [pgbr-geral] Particionamento x Herança

[JotaComm]

Em 25 de março de 2010 14:45, letgaude letga...@gmail.com escreveu:


 Que massa !! Não vi esse detalhe em nenhum dos artigos que eu li.
 Mais uma pergunta: é indicado criar um tablespace para cada partição ? E os
 indices ? Devem ser particionados também ?

 Com relação a criar uma tablespace depende como é a sua estrutura física.
Sem informações de como está a sua estrutura física não tem como dar maiores
informações.

Índices particionados? Como você particionaria um índice?


 Obrigada !

 Letícia



 JotaComm wrote:
 
  Olá,
 
  Em 25 de março de 2010 14:09, letgaude letga...@gmail.com escreveu:
 
 
  Bom, eu fiz insert na tabela pai, ex:
 
  insert into measurement
  values
  (1, '2006-02-04', 1, 1);
 
  Depois simplesmente dei select nas duas tabelas e vi q o mesmo dado
  estava
  na tabela measurement e
  e na measurement_y2006m02.
 
 
  Na verdade não. Quando você faz um SELECT na tabela pai ele também busca
  os
  dados na tabela filha. Se você quer ver somente os dados do pai você deve
  fazer:
 
  SELECT * FROM ONLY pai;
 
 
  Mas essa seria a função da trigger/rule: antes de inserir o registro na
  tabela pai verificar a data e inserir so na filha.
 
  Quem deleta o dado da tabela pai ? Tem alguma configuração ? Outra
  trigger
  ?
 
 
  Obrigada.
 
 
 
 
 
 
  JotaComm wrote:
  
   Olá,
  
   Em 25 de março de 2010 13:59, letgaude letga...@gmail.com escreveu:
  
  
   Esta exatamente como no exemplo do link q você passou:
  
   --- TRIGGER 
   CREATE TRIGGER insert_measurement_trigger
  BEFORE INSERT ON measurement
  FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();
  
   --- FUNCTION 
   CREATE OR REPLACE FUNCTION measurement_insert_trigger()
   RETURNS TRIGGER AS $$
   BEGIN
  IF ( NEW.logdate = DATE '2006-02-01' AND
   NEW.logdate  DATE '2006-03-01' ) THEN
  INSERT INTO measurement_y2006m02 VALUES (NEW.*);
  ELSE
  RAISE EXCEPTION 'Date out of range.  Fix the
   measurement_insert_trigger() function!';
  END IF;
  RETURN NULL;
   END;
  
  
   Pode me mostrar um exemplo de que os dados estão duplicados?
  
  
   Como você fez o SELECT na tabela pai e na tabela filha. Você usou
 a
   clausula ONLY na tabela pai quando fez o SELECT?
  
  
  
  
   JotaComm wrote:
   
Olá,
   
Em 25 de março de 2010 13:50, letgaude letga...@gmail.com
  escreveu:
   
   
Desculpe o ROLE. Foi falta de atenção mesmo.
   
Mas, voltando ao assunto. Eu ja tinha visto esse artigo e foi
   exatamente
o
exemplo q eu usei pra testar. E gerou dados na tabela measurement
 e
  na
measurement_y2006m02, por exemplo.
   
   
   
   
Mas ao criar as tabelas sem heranca isso nao aconteceu.
   
   
Acho que tem alguma coisa errada na sua implementação. Como está o
   RETURN
da
sua função? Está com RETURN NULL ou RETURN NEW?
   
   
   
   
JotaComm wrote:

 Olá,

 Em 25 de março de 2010 12:07, letgaude letga...@gmail.com
   escreveu:


 Boa Tarde,

 Em todos os foruns sobre particionamento, é dito que a
   implementação
 desta
 é
 feita através de herança. Que precisa criar uma trigger ou role
  pra
 redirecionar os registros para as tabelas filhas e etc. No
  entanto,
com
a
 herança, os dados acabam ficando nas duas tabelas, gerando
redundância.
É
 assim mesmo ? Acho que vou particionar sem herança, pois assim
  não
gero
 duplicação de informações.


 Sim, é por herança. Você precisa de uma trigger ou rule e não
  role.

 Não vejo como ficarem dados duplicados, a menos que a trigger ou
  a
   rule
 esteja implementa de forma incorreta.

 Veja mais informações em:

  http://www.postgresql.org/docs/8.4/interactive/ddl-partitioning.html



 Grata,

 Letícia
 --
 View this message in context:

   
  
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28030200.html
 Sent from the PostgreSQL - Brasil mailing list archive at
   Nabble.com.

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br

   https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




 Atenciosamente

 --
 JotaComm
 http://jotacomm.wordpress.com

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br

  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


   
--
View this message in context:
   
  
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28031730.html
Sent from the PostgreSQL - Brasil mailing list archive at
  Nabble.com.
   
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
   
  

Re: [pgbr-geral] Particionamento x Herança

[letgaude]

Atualmente temos cerca de 50 tabelas, sendo que 3 delas possuem cerca de 734
milhoes de registros cada uma, outras com pouco mais de 600 mil e algumas
outras tabelas de configuracao pequenas. Criamos um tablespace para dados e
outro para indice. Essas tabelas gigantes é que serão particionadas. Por
isso perguntei se com a tabela particionada também é indicado criar um
tablespace para cada partição, pois assim teriamos um gerenciamento melhor
sobre o espaço ocupado.  Com relaçao ao particonamento de indices, perguntei
por causa do SQL Server. Não sei se existe esse conceito no Postgres.

Att.,

Letícia




JotaComm wrote:
 
 Em 25 de março de 2010 14:45, letgaude letga...@gmail.com escreveu:
 

 Que massa !! Não vi esse detalhe em nenhum dos artigos que eu li.
 Mais uma pergunta: é indicado criar um tablespace para cada partição ? E
 os
 indices ? Devem ser particionados também ?

 Com relação a criar uma tablespace depende como é a sua estrutura física.
 Sem informações de como está a sua estrutura física não tem como dar
 maiores
 informações.
 
 Índices particionados? Como você particionaria um índice?
 
 
 Obrigada !

 Letícia



 JotaComm wrote:
 
  Olá,
 
  Em 25 de março de 2010 14:09, letgaude letga...@gmail.com escreveu:
 
 
  Bom, eu fiz insert na tabela pai, ex:
 
  insert into measurement
  values
  (1, '2006-02-04', 1, 1);
 
  Depois simplesmente dei select nas duas tabelas e vi q o mesmo dado
  estava
  na tabela measurement e
  e na measurement_y2006m02.
 
 
  Na verdade não. Quando você faz um SELECT na tabela pai ele também
 busca
  os
  dados na tabela filha. Se você quer ver somente os dados do pai você
 deve
  fazer:
 
  SELECT * FROM ONLY pai;
 
 
  Mas essa seria a função da trigger/rule: antes de inserir o registro
 na
  tabela pai verificar a data e inserir so na filha.
 
  Quem deleta o dado da tabela pai ? Tem alguma configuração ? Outra
  trigger
  ?
 
 
  Obrigada.
 
 
 
 
 
 
  JotaComm wrote:
  
   Olá,
  
   Em 25 de março de 2010 13:59, letgaude letga...@gmail.com
 escreveu:
  
  
   Esta exatamente como no exemplo do link q você passou:
  
   --- TRIGGER 
   CREATE TRIGGER insert_measurement_trigger
  BEFORE INSERT ON measurement
  FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();
  
   --- FUNCTION 
   CREATE OR REPLACE FUNCTION measurement_insert_trigger()
   RETURNS TRIGGER AS $$
   BEGIN
  IF ( NEW.logdate = DATE '2006-02-01' AND
   NEW.logdate  DATE '2006-03-01' ) THEN
  INSERT INTO measurement_y2006m02 VALUES (NEW.*);
  ELSE
  RAISE EXCEPTION 'Date out of range.  Fix the
   measurement_insert_trigger() function!';
  END IF;
  RETURN NULL;
   END;
  
  
   Pode me mostrar um exemplo de que os dados estão duplicados?
  
  
   Como você fez o SELECT na tabela pai e na tabela filha. Você
 usou
 a
   clausula ONLY na tabela pai quando fez o SELECT?
  
  
  
  
   JotaComm wrote:
   
Olá,
   
Em 25 de março de 2010 13:50, letgaude letga...@gmail.com
  escreveu:
   
   
Desculpe o ROLE. Foi falta de atenção mesmo.
   
Mas, voltando ao assunto. Eu ja tinha visto esse artigo e foi
   exatamente
o
exemplo q eu usei pra testar. E gerou dados na tabela
 measurement
 e
  na
measurement_y2006m02, por exemplo.
   
   
   
   
Mas ao criar as tabelas sem heranca isso nao aconteceu.
   
   
Acho que tem alguma coisa errada na sua implementação. Como está
 o
   RETURN
da
sua função? Está com RETURN NULL ou RETURN NEW?
   
   
   
   
JotaComm wrote:

 Olá,

 Em 25 de março de 2010 12:07, letgaude letga...@gmail.com
   escreveu:


 Boa Tarde,

 Em todos os foruns sobre particionamento, é dito que a
   implementação
 desta
 é
 feita através de herança. Que precisa criar uma trigger ou
 role
  pra
 redirecionar os registros para as tabelas filhas e etc. No
  entanto,
com
a
 herança, os dados acabam ficando nas duas tabelas, gerando
redundância.
É
 assim mesmo ? Acho que vou particionar sem herança, pois
 assim
  não
gero
 duplicação de informações.


 Sim, é por herança. Você precisa de uma trigger ou rule e não
  role.

 Não vejo como ficarem dados duplicados, a menos que a trigger
 ou
  a
   rule
 esteja implementa de forma incorreta.

 Veja mais informações em:

  http://www.postgresql.org/docs/8.4/interactive/ddl-partitioning.html



 Grata,

 Letícia
 --
 View this message in context:

   
  
 
 http://old.nabble.com/Particionamento-x-Heran%C3%A7a-tp28030200p28030200.html
 Sent from the PostgreSQL - Brasil mailing list archive at
   Nabble.com.

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br

  
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




 Atenciosamente

 --
 JotaComm
 

Re: [pgbr-geral] Particionamento x Herança

[JotaComm]

Olá,
Em 25 de março de 2010 15:32, letgaude letga...@gmail.com escreveu:


 Atualmente temos cerca de 50 tabelas, sendo que 3 delas possuem cerca de
 734
 milhoes de registros cada uma, outras com pouco mais de 600 mil e algumas
 outras tabelas de configuracao pequenas. Criamos um tablespace para dados e
 outro para indice. Essas tabelas gigantes é que serão particionadas. Por
 isso perguntei se com a tabela particionada também é indicado criar um
 tablespace para cada partição, pois assim teriamos um gerenciamento melhor
 sobre o espaço ocupado.  Com relaçao ao particonamento de indices,
 perguntei
 por causa do SQL Server. Não sei se existe esse conceito no Postgres.


Tabelas grandes hein.. Merecem uma boa atenção.

Um tablespace para dados e outro para índices me parece interessante. Agora
tenho uma pergunta. Você tem mais de um disco? Storage? RAID?

Para performance é necessário as informações acima, agora para distribuição
lógica acho interessante sim o uso das tablespaces.

No PostgreSQL não existe como particionar um índice. No SQL Server eu
desconheço mas vou pesquisar sobre o assunto.


 Att.,

 Letícia




 JotaComm wrote:
 
  Em 25 de março de 2010 14:45, letgaude letga...@gmail.com escreveu:
 
 
  Que massa !! Não vi esse detalhe em nenhum dos artigos que eu li.
  Mais uma pergunta: é indicado criar um tablespace para cada partição ? E
  os
  indices ? Devem ser particionados também ?
 
  Com relação a criar uma tablespace depende como é a sua estrutura
 física.
  Sem informações de como está a sua estrutura física não tem como dar
  maiores
  informações.
 
  Índices particionados? Como você particionaria um índice?
 
 
  Obrigada !
 
  Letícia
 
 
 
  JotaComm wrote:
  
   Olá,
  
   Em 25 de março de 2010 14:09, letgaude letga...@gmail.com escreveu:
  
  
   Bom, eu fiz insert na tabela pai, ex:
  
   insert into measurement
   values
   (1, '2006-02-04', 1, 1);
  
   Depois simplesmente dei select nas duas tabelas e vi q o mesmo dado
   estava
   na tabela measurement e
   e na measurement_y2006m02.
  
  
   Na verdade não. Quando você faz um SELECT na tabela pai ele também
  busca
   os
   dados na tabela filha. Se você quer ver somente os dados do pai você
  deve
   fazer:
  
   SELECT * FROM ONLY pai;
  
  
   Mas essa seria a função da trigger/rule: antes de inserir o registro
  na
   tabela pai verificar a data e inserir so na filha.
  
   Quem deleta o dado da tabela pai ? Tem alguma configuração ? Outra
   trigger
   ?
  
  
   Obrigada.
  
  
  
  
  
  
   JotaComm wrote:
   
Olá,
   
Em 25 de março de 2010 13:59, letgaude letga...@gmail.com
  escreveu:
   
   
Esta exatamente como no exemplo do link q você passou:
   
--- TRIGGER 
CREATE TRIGGER insert_measurement_trigger
   BEFORE INSERT ON measurement
   FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();
   
--- FUNCTION 
CREATE OR REPLACE FUNCTION measurement_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
   IF ( NEW.logdate = DATE '2006-02-01' AND
NEW.logdate  DATE '2006-03-01' ) THEN
   INSERT INTO measurement_y2006m02 VALUES (NEW.*);
   ELSE
   RAISE EXCEPTION 'Date out of range.  Fix the
measurement_insert_trigger() function!';
   END IF;
   RETURN NULL;
END;
   
   
Pode me mostrar um exemplo de que os dados estão duplicados?
   
   
Como você fez o SELECT na tabela pai e na tabela filha. Você
  usou
  a
clausula ONLY na tabela pai quando fez o SELECT?
   
   
   
   
JotaComm wrote:

 Olá,

 Em 25 de março de 2010 13:50, letgaude letga...@gmail.com
   escreveu:


 Desculpe o ROLE. Foi falta de atenção mesmo.

 Mas, voltando ao assunto. Eu ja tinha visto esse artigo e foi
exatamente
 o
 exemplo q eu usei pra testar. E gerou dados na tabela
  measurement
  e
   na
 measurement_y2006m02, por exemplo.




 Mas ao criar as tabelas sem heranca isso nao aconteceu.


 Acho que tem alguma coisa errada na sua implementação. Como está
  o
RETURN
 da
 sua função? Está com RETURN NULL ou RETURN NEW?




 JotaComm wrote:
 
  Olá,
 
  Em 25 de março de 2010 12:07, letgaude letga...@gmail.com
escreveu:
 
 
  Boa Tarde,
 
  Em todos os foruns sobre particionamento, é dito que a
implementação
  desta
  é
  feita através de herança. Que precisa criar uma trigger ou
  role
   pra
  redirecionar os registros para as tabelas filhas e etc. No
   entanto,
 com
 a
  herança, os dados acabam ficando nas duas tabelas, gerando
 redundância.
 É
  assim mesmo ? Acho que vou particionar sem herança, pois
  assim
   não
 gero
  duplicação de informações.
 
 
  Sim, é por herança. Você precisa de uma trigger ou rule e não
   role.
 
  Não vejo como ficarem dados duplicados, a menos que a trigger
  ou
  

Re: [pgbr-geral] Particionamento x Herança

[letgaude]

Não temos um ambiente definitivo ainda para produção. A previsão é que
tenhamos varios storages com 360 Gb no minimo cada um. Poderíamos então
aloca-los da seguinte forma:

Tabela Pai - na tablespace PRINCIPAL

Tabela Filha1 na TABLESPACE1. Esta tabela é herança da tabela pai, portanto
particionada. Seus indices estarão na TABLESPACE1 também. Logo, estarão
particionados também. Correto ? :-)

E assim faremos para as 3 tabelas. Uma tablespace para cada uma delas,
alocadas fisicamente em storages diferentes. Um indice na mesma tablespace
do dado é mais eficiente ? 

Grata,

Letícia






letgaude wrote:
 
 Atualmente temos cerca de 50 tabelas, sendo que 3 delas possuem cerca de
 734 milhoes de registros cada uma, outras com pouco mais de 600 mil e
 algumas outras tabelas de configuracao pequenas. Criamos um tablespace
 para dados e outro para indice. Essas tabelas gigantes é que serão
 particionadas. Por isso perguntei se com a tabela particionada também é
 indicado criar um tablespace para cada partição, pois assim teriamos um
 gerenciamento melhor sobre o espaço ocupado.  Com relaçao ao
 particonamento de indices, perguntei por causa do SQL Server. Não sei se
 existe esse conceito no Postgres.
 
 Att.,
 
 Letícia
 
 
 
 
 JotaComm wrote:
 
 Em 25 de março de 2010 14:45, letgaude letga...@gmail.com escreveu:
 

 Que massa !! Não vi esse detalhe em nenhum dos artigos que eu li.
 Mais uma pergunta: é indicado criar um tablespace para cada partição ? E
 os
 indices ? Devem ser particionados também ?

 Com relação a criar uma tablespace depende como é a sua estrutura
 física.
 Sem informações de como está a sua estrutura física não tem como dar
 maiores
 informações.
 
 Índices particionados? Como você particionaria um índice?
 
 
 Obrigada !

 Letícia



 JotaComm wrote:
 
  Olá,
 
  Em 25 de março de 2010 14:09, letgaude letga...@gmail.com escreveu:
 
 
  Bom, eu fiz insert na tabela pai, ex:
 
  insert into measurement
  values
  (1, '2006-02-04', 1, 1);
 
  Depois simplesmente dei select nas duas tabelas e vi q o mesmo dado
  estava
  na tabela measurement e
  e na measurement_y2006m02.
 
 
  Na verdade não. Quando você faz um SELECT na tabela pai ele também
 busca
  os
  dados na tabela filha. Se você quer ver somente os dados do pai você
 deve
  fazer:
 
  SELECT * FROM ONLY pai;
 
 
  Mas essa seria a função da trigger/rule: antes de inserir o registro
 na
  tabela pai verificar a data e inserir so na filha.
 
  Quem deleta o dado da tabela pai ? Tem alguma configuração ? Outra
  trigger
  ?
 
 
  Obrigada.
 
 
 
 
 
 
  JotaComm wrote:
  
   Olá,
  
   Em 25 de março de 2010 13:59, letgaude letga...@gmail.com
 escreveu:
  
  
   Esta exatamente como no exemplo do link q você passou:
  
   --- TRIGGER 
   CREATE TRIGGER insert_measurement_trigger
  BEFORE INSERT ON measurement
  FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();
  
   --- FUNCTION 
   CREATE OR REPLACE FUNCTION measurement_insert_trigger()
   RETURNS TRIGGER AS $$
   BEGIN
  IF ( NEW.logdate = DATE '2006-02-01' AND
   NEW.logdate  DATE '2006-03-01' ) THEN
  INSERT INTO measurement_y2006m02 VALUES (NEW.*);
  ELSE
  RAISE EXCEPTION 'Date out of range.  Fix the
   measurement_insert_trigger() function!';
  END IF;
  RETURN NULL;
   END;
  
  
   Pode me mostrar um exemplo de que os dados estão duplicados?
  
  
   Como você fez o SELECT na tabela pai e na tabela filha. Você
 usou
 a
   clausula ONLY na tabela pai quando fez o SELECT?
  
  
  
  
   JotaComm wrote:
   
Olá,
   
Em 25 de março de 2010 13:50, letgaude letga...@gmail.com
  escreveu:
   
   
Desculpe o ROLE. Foi falta de atenção mesmo.
   
Mas, voltando ao assunto. Eu ja tinha visto esse artigo e foi
   exatamente
o
exemplo q eu usei pra testar. E gerou dados na tabela
 measurement
 e
  na
measurement_y2006m02, por exemplo.
   
   
   
   
Mas ao criar as tabelas sem heranca isso nao aconteceu.
   
   
Acho que tem alguma coisa errada na sua implementação. Como está
 o
   RETURN
da
sua função? Está com RETURN NULL ou RETURN NEW?
   
   
   
   
JotaComm wrote:

 Olá,

 Em 25 de março de 2010 12:07, letgaude letga...@gmail.com
   escreveu:


 Boa Tarde,

 Em todos os foruns sobre particionamento, é dito que a
   implementação
 desta
 é
 feita através de herança. Que precisa criar uma trigger ou
 role
  pra
 redirecionar os registros para as tabelas filhas e etc. No
  entanto,
com
a
 herança, os dados acabam ficando nas duas tabelas, gerando
redundância.
É
 assim mesmo ? Acho que vou particionar sem herança, pois
 assim
  não
gero
 duplicação de informações.


 Sim, é por herança. Você precisa de uma trigger ou rule e não
  role.

 Não vejo como ficarem dados duplicados, a menos que a trigger
 ou
  a
   rule
 esteja implementa de forma incorreta.

 Veja 

Re: [pgbr-geral] Particionamento x Herança

[Andre Fernandes]

Em 25 de março de 2010 16:52, letgaude letga...@gmail.com escreveu:


 Não temos um ambiente definitivo ainda para produção. A previsão é que
 tenhamos varios storages com 360 Gb no minimo cada um. Poderíamos então
 aloca-los da seguinte forma:

 Tabela Pai - na tablespace PRINCIPAL

 Tabela Filha1 na TABLESPACE1. Esta tabela é herança da tabela pai, portanto
 particionada. Seus indices estarão na TABLESPACE1 também. Logo, estarão
 particionados também. Correto ? :-)


E assim faremos para as 3 tabelas. Uma tablespace para cada uma delas,
 alocadas fisicamente em storages diferentes. Um indice na mesma tablespace
 do dado é mais eficiente ?

 Normalmente o índice em uma tablespace própria é mais eficiente. Mas como
toda regra, pode ter exceção.
No teu caso, para ter uma boa performance, consideraria colocar os índices
em uma partição distinta (somente para os índices).


 Grata,

 Letícia



Atenciosamente,

-- 
André de Camargo Fernandes
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento

[Euler Taveira de Oliveira]

Thiago Freitas escreveu:
 Tenho uma tabela muito grande e queria dividi-la em pedaços menores, por
 exemplo, MÊS/ANO.
O que é muito grande?

 Eu teria que utilizar o conceito de herança para criar todas as tabelas
 filhas herdando as características da tabela principal.
 Depois, eu teria que criar triggers para cada insert executado e criar
 views para visualizar os dados particionados por MÊS/ANO.
Não. O gatilho para inserção é só um (na tabela pai); o que precisa ser mudado
é a função disparada no gatilho pois a mesma precisa saber que existe uma nova
partição.

Visões? Para que?

 No entanto, terei o problema de manutenção dessas N
 tabelas/views/triggers/indices criadas para o particionamento.
 Esta é realmente a melhor forma de se particionar?
Não é a forma definitiva mas é a que temos disponível hoje. Houve um esforço
para termos algo definitivo mas tal funcionalidade (automatizar o
gerenciamento de partições) não virá na próxima versão. :( Inclusive, é de meu
interesse participar do processo de desenvolvimento desta funcionalidade (mas
isso só acontecerá daqui a alguns meses quando provavelmente abriremos um
outro _branch_ no repositório para o 9.1).

 Ainda, fazendo o particionamento o tamanho do banco aumentará
 consideravelmente ou não?
 
Não. Os dados estarão em partições (aka tabelas filho) ao invés de uma tabela
(aka tabela pai); a mesma lógica vale para os índices dessas partições.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Particionamento

[Thiago Freitas]

Pessoal, estava lendo sobre particionamento no PostgreSQL e surgiu a
seguinte dúvida:
Tenho uma tabela muito grande e queria dividi-la em pedaços menores, por
exemplo, MÊS/ANO.
Eu teria que utilizar o conceito de herança para criar todas as tabelas
filhas herdando as características da tabela principal.
Depois, eu teria que criar triggers para cada insert executado e criar views
para visualizar os dados particionados por MÊS/ANO.
Todas estas alterações trarão melhor performance para as consultas.
No entanto, terei o problema de manutenção dessas N
tabelas/views/triggers/indices criadas para o particionamento.
Esta é realmente a melhor forma de se particionar?
Ainda, fazendo o particionamento o tamanho do banco aumentará
consideravelmente ou não?

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

[pgbr-geral] Particionamento

[Guilherme Vianna de Aguiar]

Boa tarde, 

alguem experiencia em particionamento?

 

Tenho algumas duvidas

 

1.   Trigger X rule. Na documentacao diz que rule eh melhor para grande
volume de dados na insercao. Mas em que em certas situacoes trigger eh mais
indicado.

2.   A performance piora no caso de atualizacao? Já que teria que apagar
registro de uma particao e inserir em outra.

3.   A alternativa de criar uma view ( e não usar particionamento) eh
satisfatoria?

4.   Ha como buscar os registros ‘perdidos’ na tabela principal (que nao
se encaixaram nas condicoes das particoes criadas) usando função ou views
nativas?

5.   Usar particoes em um DW com milhoes de registros melhoraria o tempo
das consultas?

 

Obrigado,

Guilherme Vianna

 

 

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

[pgbr-geral] Particionamento tabela

[Vinicius]

Ola pessoal, estive lendo um aritgo de Fabio Telles sobre 
particionamento de tabela muito grandes. Como isso funciona e como eh 
feito ?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento tabela

[Leandro DUTRA]

2008/3/30, Vinicius [EMAIL PROTECTED]:
 Ola pessoal, estive lendo um aritgo de Fabio Telles sobre
  particionamento de tabela muito grandes. Como isso funciona e como eh
  feito ?

A tabela poder ser dividida em tabelas menores, por exemplo de acordo
com faixas de valores.  No PostgreSQL, ainda é feito com uma gambiarra
de herança — aliás é a única utilidade real da herança de tabelas
hoje.

-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Particionamento de tabelas

[Ribamar Sousa]

Olá!

Estou lendo o livro PostgreSQL 8 for Windows do Richard Blum e
coincidentemente com nossa discussão sobre herança de tabelas ele
aborda na página 22 o Table Partitioning.

Não somente aqui na lista eu já ouvi de outras fontes que devemos
evitar herança em tabelas no postgresql. Inclusive da equipe de
desenvolvimento do PG (sei que aqui encontram-se alguns).

Como é um recurso avançado e interessante eu gostaria de saber o grau
de confiabilidade do mesmo, que também usa herança em tabelas:

http://www.postgresql.org/docs/8.3/interactive/ddl-partitioning.html

Gostaria de ouvir a opinião dos colegas mais experientes com o PostgreSQL.

Sei que é até lógico mas vou perguntar:
Este e outros recursos que utilizem herança de tabelas devem ser evitados?

-- 
Ribamar FS - ribafs [ ] gmail.com
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Particionamento de tabelas

[Euler Taveira de Oliveira]

Ribamar Sousa wrote:

 Não somente aqui na lista eu já ouvi de outras fontes que devemos
 evitar herança em tabelas no postgresql. Inclusive da equipe de
 desenvolvimento do PG (sei que aqui encontram-se alguns).
 
O seu uso é desaconselhável porque o mínimo que se espera da herança 
(chaves primárias, restrição de unicidade) não funciona no estado atual.

 Como é um recurso avançado e interessante eu gostaria de saber o grau
 de confiabilidade do mesmo, que também usa herança em tabelas:
 

corte

 Sei que é até lógico mas vou perguntar:
 Este e outros recursos que utilizem herança de tabelas devem ser evitados?
 
A herança foi só um truque para implementar o particionamento de tabelas 
  e não ter que escrever muito código para isso. Foi um serviço de 
preguiçoso mas funciona razoavelmente bem. ;) De herança o 
particionamento de tabelas não tem quase nada, a não ser uma única 
referência (a tabela pai).
No estado atual o particionamento funciona bem mas ele possue as suas 
limitações. A principal desvantagem dessa implementação de 
particionamento é o alto custo de manutenção. Aconselho que leia [1] 
sobre a implementação usando regras ao invés de gatilhos (em alguns 
casos elas podem ser utilizadas). E como toda solução não é perfeita, 
leia também os problemas (caveats).
No mês passado foi iniciado uma discussão [2] na -hackers sobre a 
sintaxe/implementação do que vai ser o particionamento de tabelas no 
PostgreSQL. Possivelmente teremos isso para o 8.4. Vamos ver o andar da 
carruagem...

[1] http://www.postgresql.org/docs/current/static/ddl-partitioning.html
[2] http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php


-- 
   Euler Taveira de Oliveira
   http://www.timbira.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral