Re: [pgbr-geral] [memória autovacuum]

2016-05-03 Por tôpico Euler Taveira 
On 03-05-2016 16:17, Daniel Luiz da Silva wrote:
> - mesmo utilizando 24MB, na sessão, e demorando 40 mintuos, porque não
> utilizou total disponível 32MB, como funciona o rastreio de tuplas não
> vigentes?
>
Ele pode ter demorado tanto tempo assim porque a tabela está muito
inchada e/ou o autovacuum_vacuum_cost_delay está alto. Outra teoria é
porque ele estava fazendo FREEZE. Quanto ao tamanho, como você mediu os
24 MB? Para o rastreio são geralmente 6 bytes por tupla não vigente.
Além disso, o worker não é só memória para rastreio. Como você mediu 24
MB? RES? VIRT?

> - é um processo do autovacuum, e não wrap-around;
>
Tenha em mente que o autovacuum pode disparar para realizar ação
anti-wraparound.

> - Segue estatísticas da tabela:
> relname;
> seq_scan;seq_tup_read;idx_scan;idx_tup_fetch;n_tup_ins;n_tup_upd;n_tup_del;n_tup_hot_upd;n_live_tup;n_dead_tup;last_vacuum;last_autovacuum;last_analyze;last_autoanalyze
> "tbsession";33874;63090745;64590117;62505457;1051135;31172552;1050387;29656406;2159;55577;"30/04/2016
> 13:07:15";"03/05/2016 16:01:44";"30/04/2016 13:07:15";"03/05/2016 16:01:45"
> Tamanho total 11.3GB
> 
A sua tabela está exageradamente inchada (2159 tuplas vigentes e 55.577
tuplas não-vigentes). Para ter 11 GB, deve haver muitas páginas quase
vazias. Neste caso, eu aconselho executar o VACUUM FULL para voltar ao
tamanho normal. O autovacuum está desabilitado nessa tabela?

> Minha preocupação final além disso é porque trata-se uma tabela com muio
> update, ou seja, muito inchada, porém, estou estudando para entender
> e tratar essa tabela.
> 
Talvez você precise de: (i) valores personalizados do autovacuum ou (ii)
uma rotina manual.


-- 
   Euler Taveira   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] Funcão PostgreSQL 9.2

2016-05-03 Por tôpico drum.lu...@gmail.com 
Só atualizando a function tf_users_update_code_column..

Incluido o campo *AND NEW.code IS NULL , *para que o usuário possa incluir
o valor que quiser, e caso ele não inclua, a funcao insere os dados
necessário.

- Tinha esquecido dessa parte antes, por isto decidi postar todo o código
aqui novamente, para que fique melhor de entender.


IF NEW.company_id = 1 AND NEW.code IS NULL THEN
> NEW.code = NEXTVAL('c1_users_code_seq');



CODE:

1 - creating the trigger FUNCTION

CREATE OR REPLACE FUNCTION tf_users_update_code_column()

  RETURNS trigger AS $$

  BEGIN



IF NEW.company_id = 1 AND NEW.code IS NULL THEN

NEW.code = NEXTVAL('c1_users_code_seq');

ELSEIF NEW.company_id = 2 AND NEW.code IS NULL THEN

NEW.code = NEXTVAL('c2_users_code_seq');

ELSEIF NEW.company_id = 3 AND NEW.code IS NULL THEN

NEW.code = NEXTVAL('c3_users_code_seq');

ELSEIF NEW.company_id = 4 AND NEW.code IS NULL THEN

NEW.code = NEXTVAL('c4_users_code_seq');

ELSEIF NEW.company_id = 5 AND NEW.code IS NULL THEN

NEW.code = NEXTVAL('c5_users_code_seq');

ELSEIF NEW.company_id = 6 AND NEW.code IS NULL THEN

NEW.code = NEXTVAL('c6_users_code_seq');

ELSEIF NEW.company_id = 7 AND NEW.code IS NULL THEN

NEW.code = NEXTVAL('c7_users_code_seq');

ELSEIF NEW.company_id = 8 AND NEW.code IS NULL THEN

NEW.code = NEXTVAL('c8_users_code_seq');

ELSEIF NEW.company_id = 9 AND NEW.code IS NULL THEN

NEW.code = NEXTVAL('c9_users_code_seq');

ELSEIF NEW.company_id = 10 AND NEW.code IS NULL THEN

NEW.code = NEXTVAL('c10_users_code_seq');



  END IF;



  return NEW;



  END



$$  LANGUAGE plpgsql;

2 - Creating the sequences

CREATE SEQUENCE c1_users_code_seq

INCREMENT 1

MINVALUE 1

MAXVALUE 9223372036854775807

START 1000;

CACHE 1;

CREATE SEQUENCE c2_users_code_seq

INCREMENT 1

MINVALUE 1

MAXVALUE 9223372036854775807

START 1000;

CACHE 1;

CREATE SEQUENCE c3_users_code_seq

INCREMENT 1

MINVALUE 1

MAXVALUE 9223372036854775807

START 1000;

CACHE 1;

CREATE SEQUENCE c4_users_code_seq

INCREMENT 1

MINVALUE 1

MAXVALUE 9223372036854775807

START 1000;

CACHE 1;


> ... [etc] ...

3 - Creating the TRIGGER

CREATE TRIGGER t_users_update_code_column

  BEFORE INSERT

  ON users

  FOR EACH ROW

  EXECUTE PROCEDURE tf_users_update_code_column();
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

2016-05-03 Por tôpico drum.lu...@gmail.com 
>
>
> 1 - Criando a funcao
>
> CREATE OR REPLACE FUNCTION tf_users_update_code_column()
>   RETURNS trigger AS $$
>
>   BEGIN
>
> IF NEW.company_id = 1 THEN
> NEW.code = NEXTVAL('c1_users_code_seq');
>
> ELSEIF NEW.company_id = 2 THEN
> NEW.code = NEXTVAL('c2_users_code_seq');
>
> ELSEIF NEW.company_id = 3 THEN
> NEW.code = NEXTVAL('c3_users_code_seq');
>
> ELSEIF NEW.company_id = 4 THEN
> NEW.code = NEXTVAL('c4_users_code_seq');
>
> ELSEIF NEW.company_id = 5 THEN
> NEW.code = NEXTVAL('c5_users_code_seq');
>
> ELSEIF NEW.company_id = 6 THEN
> NEW.code = NEXTVAL('c6_users_code_seq');
>
> ELSEIF NEW.company_id = 7 THEN
> NEW.code = NEXTVAL('c7_users_code_seq');
>
> ELSEIF NEW.company_id = 8 THEN
> NEW.code = NEXTVAL('c8_users_code_seq');
>
> ELSEIF NEW.company_id = 9 THEN
> NEW.code = NEXTVAL('c9_users_code_seq');
>
> ELSEIF NEW.company_id = 10 THEN
> NEW.code = NEXTVAL('c10_users_code_seq');
>
>   END IF;
>
>   return NEW;
>
>   END
> $$  LANGUAGE plpgsql;
>
> 2 - Criando as seq
>
> CREATE SEQUENCE c1_users_code_seq
> INCREMENT 1
> MINVALUE 1
> MAXVALUE 9223372036854775807  START 1000;
> CACHE 1;
> CREATE SEQUENCE c2_users_code_seq
> INCREMENT 1
> MINVALUE 1
> MAXVALUE 9223372036854775807  START 1000;
> CACHE 1;
> CREATE SEQUENCE c3_users_code_seq
> INCREMENT 1
> MINVALUE 1
> MAXVALUE 9223372036854775807  START 1000;
> CACHE 1;
> CREATE SEQUENCE c4_users_code_seq
> INCREMENT 1
> MINVALUE 1
> MAXVALUE 9223372036854775807  START 1000;
> CACHE 1;
>
> ... [etc] ...
>
> 3 - Criando o TRIGGER
>
> CREATE TRIGGER t_users_update_code_column
>   BEFORE UPDATE OR INSERT
>   ON users
>   FOR EACH ROW
>   EXECUTE PROCEDURE tf_users_update_code_column();
>
>
>
>
> Isso funciona bem. Sem nenhum problema.
>
> O único problema é que eu teria milhares de seq para criar, pois haverá
> milhares de clientes.
> Isto é simplesmente inviável.
>
> - Por favor, baseado no que forneci a cima, poderiam dar alguma luz sobre
> como fazer o mesmo, mas mais "simples"? Talvez utilizar uma outra tabela
> para armazenar os dados, como já mencionado.
>
> Obrigado.
> Lucas
>
>

Ops... acabei de ver um erro meu:

- Antes de INSERT e não de UPDATE/INSERT


CREATE TRIGGER t_users_update_code_column
  BEFORE INSERT
  ON users
  FOR EACH ROW
  EXECUTE PROCEDURE tf_users_update_code_column();
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

2016-05-03 Por tôpico drum.lu...@gmail.com 
2016-05-04 1:40 GMT+12:00 Euler Taveira :

> On 03-05-2016 01:02, drum.lu...@gmail.com wrote:
> > 1 - cada usuário na tabela users faz parte de uma empresa, essa empresa
> > é "determinada"  pela coluna company_id na tabela users.
> >
> > 2 - Cada usuário, inclui os dados dentro de users.code, mas se ele não
> > incluir, a sequencia faz o trabalho.
> >
> > A questão, é que o valor default é de 1000, mas para cada empresa:
> >
> Você não resolve esse problema com sequências (a não ser que possa
> existir "buracos"). Para sequências que não podem ter buracos, é
> obrigatório o uso de uma tabela para controle da sequência. No seu caso,
> basta ter uma tabela de controle contendo campos (empresa, sequencia).
> Para fazer o INSERT, você deve codificar em alguma linguagem procedural
> ou mesmo na linguagem utilizada porque é necessário testar se 'code' foi
> informado ou não.
>
>

1 - Criando a funcao

CREATE OR REPLACE FUNCTION tf_users_update_code_column()
  RETURNS trigger AS $$

  BEGIN

IF NEW.company_id = 1 THEN
NEW.code = NEXTVAL('c1_users_code_seq');

ELSEIF NEW.company_id = 2 THEN
NEW.code = NEXTVAL('c2_users_code_seq');

ELSEIF NEW.company_id = 3 THEN
NEW.code = NEXTVAL('c3_users_code_seq');

ELSEIF NEW.company_id = 4 THEN
NEW.code = NEXTVAL('c4_users_code_seq');

ELSEIF NEW.company_id = 5 THEN
NEW.code = NEXTVAL('c5_users_code_seq');

ELSEIF NEW.company_id = 6 THEN
NEW.code = NEXTVAL('c6_users_code_seq');

ELSEIF NEW.company_id = 7 THEN
NEW.code = NEXTVAL('c7_users_code_seq');

ELSEIF NEW.company_id = 8 THEN
NEW.code = NEXTVAL('c8_users_code_seq');

ELSEIF NEW.company_id = 9 THEN
NEW.code = NEXTVAL('c9_users_code_seq');

ELSEIF NEW.company_id = 10 THEN
NEW.code = NEXTVAL('c10_users_code_seq');

  END IF;

  return NEW;

  END
$$  LANGUAGE plpgsql;

2 - Criando as seq

CREATE SEQUENCE c1_users_code_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807  START 1000;
CACHE 1;
CREATE SEQUENCE c2_users_code_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807  START 1000;
CACHE 1;
CREATE SEQUENCE c3_users_code_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807  START 1000;
CACHE 1;
CREATE SEQUENCE c4_users_code_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807  START 1000;
CACHE 1;

... [etc] ...

3 - Criando o TRIGGER

CREATE TRIGGER t_users_update_code_column
  BEFORE UPDATE OR INSERT
  ON users
  FOR EACH ROW
  EXECUTE PROCEDURE tf_users_update_code_column();




Isso funciona bem. Sem nenhum problema.

O único problema é que eu teria milhares de seq para criar, pois haverá
milhares de clientes.
Isto é simplesmente inviável.

- Por favor, baseado no que forneci a cima, poderiam dar alguma luz sobre
como fazer o mesmo, mas mais "simples"? Talvez utilizar uma outra tabela
para armazenar os dados, como já mencionado.

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

Re: [pgbr-geral] Minievento FISL

2016-05-03 Por tôpico Fernando Foster 
Sobre o FISL tenho o interesse em ir. Alguém mais vai?

Em seg, 2 de mai de 2016 às 23:37, Alvaro Melo 
escreveu:

> Olá pessoal,
>
> Depois de um longo hiato, vou tentar voltar retomar a utilização da
> lista rotineiramente.
>
> E queria começar fazendo um mea culpa. Por não estar utilizando a lista,
> não sabia do minievento. Então mandei uma palestra para o FISL, e fiquei
> muito contente por ela ter sido aceita, ainda mais no espaço da comunidade.
>
> Fico à disposição para ajudar no que for possível, mesmo estando não tão
> perto de Porto Alegre.
>
> Att.,
>
> --
> Álvaro Nunes MeloAtua Sistemas de Informação
> alv...@atua.com.br   http://www.atua.com.br
> (54) 9976-0106   (54) 3045-8100
>
> ___
> 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] [memória autovacuum]

2016-05-03 Por tôpico Daniel Luiz da Silva 
Euller, 

Agradeço sua resposta. Segue considerações: 

- sobre o parâmetro, utilizei o nome errado, me refiro ao parâmetro 
autovacuum_max_workers , presente na versão 9.0.10; 
- mesmo utilizando 24MB, na sessão, e demorando 40 mintuos, porque não utilizou 
total disponível 32MB, como funciona o rastreio de tuplas não vigentes? 
- é um processo do autovacuum, e não wrap-around; 
- Segue estatísticas da tabela: 
relname; 
seq_scan;seq_tup_read;idx_scan;idx_tup_fetch;n_tup_ins;n_tup_upd;n_tup_del;n_tup_hot_upd;n_live_tup;n_dead_tup;last_vacuum;last_autovacuum;last_analyze;last_autoanalyze
 
"tbsession";33874;63090745;64590117;62505457;1051135;31172552;1050387;29656406;2159;55577;"30/04/2016
 13:07:15";"03/05/2016 16:01:44";"30/04/2016 13:07:15";"03/05/2016 16:01:45" 
Tamanho total 11.3GB 

- sobre atualização do postgres, está em curso a execução de atualização para 
versão do Postgres. 

Minha preocupação final além disso é porque trata-se uma tabela com muio 
update, ou seja, muito inchada, porém, estou estudando para entender e tratar 
essa tabela. 

Obrigado. 





De: "Euler Taveira"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Terça-feira, 3 de maio de 2016 15:45:57 
Assunto: Re: [pgbr-geral] [memória autovacuum] 

On 03-05-2016 15:10, Daniel Luiz da Silva wrote: 
> Tenho castrado 32MB para o parâmetro maintenance_work_mem e 3 para 
> autovacuum_work_men. 
> Porém ao executar um processo de autovaccum de uma tabela específica a 
> memória utilizada de acordo com Sistema Operacional é de 24MB. 
> 
Na versão 9.0 *não* existe o parâmetro autovacuum_work_mem; utilize 
maintenance_work_mem. 

> Minha dúvida é sobre a quantidade de memória que um processo de 
> autovaccum pode utilizar, ou seja, de acordo com a documentação postgres 
> (http://www.postgresql.org/docs/9.1/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY),
>  
> esse valor é igual a quantidade de memória disponível para manutenção, 
> vezes a quantidade de processo autovaccum que podem rodar em paralelo. 
> No meu caso resulta 96MB. Por fim o processo estava executando 
> autovaccum a mais de 40min, utilizando no máximo 24MB, e apenas um 
> processo de autovaccum rodando. O SGBD não deveria utilizar o total 
> disponível para esse caso, levando em conta que além disso o servidor 
> estava com bastante memória disponível? 
> 
Não. Ele pode usar *até* maintenance_work_mem (ou autovacuum_work_mem) 
para rastreio de tuplas não vigentes. Cada processo do autovacuum vai 
usar no máximo maintenance_work_mem (ou autovacuum_work_mem), ou seja, 
como você só tem um processo usará no máximo 32 MB. 

É um worker do autovacuum normal ou anti-wraparound? Além disso, forneça 
as estatísticas (pg_stat_user_tables) e o tamanho da referida tabela. 


PS> sempre leia a documentação relativa a sua versão (9.0) e não versões 
recentes pois podem haver mudanças significativas. 

PS2> a 9.0 foi descontinuada a 7 meses. Considere atualizar a versão o 
quanto antes. 


-- 
Euler Taveira 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 mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [memória autovacuum]

2016-05-03 Por tôpico Euler Taveira 
On 03-05-2016 15:10, Daniel Luiz da Silva wrote:
> Tenho castrado 32MB para o parâmetro maintenance_work_mem e 3 para
> autovacuum_work_men.
> Porém ao executar um processo de autovaccum de uma tabela específica a
> memória utilizada de acordo com Sistema Operacional é de 24MB.
>
Na versão 9.0 *não* existe o parâmetro autovacuum_work_mem; utilize
maintenance_work_mem.

> Minha dúvida é sobre a quantidade de memória que um processo de
> autovaccum pode utilizar, ou seja, de acordo com a documentação postgres
> (http://www.postgresql.org/docs/9.1/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY),
> esse valor é igual a quantidade de memória disponível para manutenção,
> vezes a quantidade de processo autovaccum que podem rodar em paralelo.
> No meu caso resulta 96MB. Por fim o processo estava executando
> autovaccum a mais de 40min, utilizando no máximo 24MB, e apenas um
> processo de autovaccum rodando. O SGBD não deveria utilizar o total
> disponível para esse caso, levando em conta que além disso o servidor
> estava com bastante memória disponível?
> 
Não. Ele pode usar *até* maintenance_work_mem (ou autovacuum_work_mem)
para rastreio de tuplas não vigentes. Cada processo do autovacuum vai
usar no máximo maintenance_work_mem (ou autovacuum_work_mem), ou seja,
como você só tem um processo usará no máximo 32 MB.

É um worker do autovacuum normal ou anti-wraparound? Além disso, forneça
as estatísticas (pg_stat_user_tables) e o tamanho da referida tabela.


PS> sempre leia a documentação relativa a sua versão (9.0) e não versões
recentes pois podem haver mudanças significativas.

PS2> a 9.0 foi descontinuada a 7 meses. Considere atualizar a versão o
quanto antes.


-- 
   Euler Taveira   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] [memória autovacuum]

2016-05-03 Por tôpico Daniel Luiz da Silva 
Olá pessoal, 

Tenho castrado 32MB para o parâmetro maintenance_work_mem e 3 para 
autovacuum_work_men. 
Porém ao executar um processo de autovaccum de uma tabela específica a memória 
utilizada de acordo com Sistema Operacional é de 24MB. 
Minha dúvida é sobre a quantidade de memória que um processo de autovaccum pode 
utilizar, ou seja, de acordo com a documentação postgres 
(http://www.postgresql.org/docs/9.1/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY),
 esse valor é igual a quantidade de memória disponível para manutenção, vezes a 
quantidade de processo autovaccum que podem rodar em paralelo. No meu caso 
resulta 96MB. Por fim o processo estava executando autovaccum a mais de 40min, 
utilizando no máximo 24MB, e apenas um processo de autovaccum rodando. O SGBD 
não deveria utilizar o total disponível para esse caso, levando em conta que 
além disso o servidor estava com bastante memória disponível? 

Meu postgres é versão 9.0.10. 

Configuração de autovacuum 

"autovacuum";"on" 
"autovacuum_analyze_scale_factor";"0.05" 
"autovacuum_analyze_threshold";"10" 
"autovacuum_freeze_max_age";"2" 
"autovacuum_max_workers";"3" 
"autovacuum_naptime";"60" 
"autovacuum_vacuum_cost_delay";"20" 
"autovacuum_vacuum_cost_limit";"-1" 
"autovacuum_vacuum_scale_factor";"0.2" 
"autovacuum_vacuum_threshold";"50" 
"log_autovacuum_min_duration";"-1" 

Configuração de memória 
"maintenance_work_mem";"32768" 
"work_mem";"24576" 
"shared_buffers";"47104" 
"temp_buffers";"2048" 

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

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

2016-05-03 Por tôpico Euler Taveira 
On 03-05-2016 01:02, drum.lu...@gmail.com wrote:
> 1 - cada usuário na tabela users faz parte de uma empresa, essa empresa
> é "determinada"  pela coluna company_id na tabela users.
> 
> 2 - Cada usuário, inclui os dados dentro de users.code, mas se ele não
> incluir, a sequencia faz o trabalho.
> 
> A questão, é que o valor default é de 1000, mas para cada empresa:
> 
Você não resolve esse problema com sequências (a não ser que possa
existir "buracos"). Para sequências que não podem ter buracos, é
obrigatório o uso de uma tabela para controle da sequência. No seu caso,
basta ter uma tabela de controle contendo campos (empresa, sequencia).
Para fazer o INSERT, você deve codificar em alguma linguagem procedural
ou mesmo na linguagem utilizada porque é necessário testar se 'code' foi
informado ou não.


-- 
   Euler Taveira   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] [Postgres 9.0] Teste de reorganização de páginas

2016-05-03 Por tôpico Daniel Luiz da Silva 
Bom dia, 
Pessoal, 

Estou realizando um teste para identificar tabelas inchadas (bloat table) na 
minha database. Porém fiquei com dúvida sobre o funcionamento do VACUUM. 
Tenho o seguinte cenário: 

-- create da tabela 
create table a ( nm text ); 

-- inserção de registros 
insert into a values (repeat(md5(random()::text),2) ); 
insert into a values (repeat(md5(random()::text),2) ); 
insert into a values (repeat(md5(random()::text),2) ); 
insert into a values (repeat(md5(random()::text),2) ); 
insert into a values (repeat(md5(random()::text),2) ); 
insert into a values (repeat(md5(random()::text),2) ); 
insert into a values (repeat(md5(random()::text),2) ); 
insert into a values (repeat(md5(random()::text),2) ); 
insert into a values (repeat(md5(random()::text),2) ); 
insert into a values (repeat(md5(random()::text),2) ); 

-- todos os valores sequenciamente colocados em páginas 
select ctid, nm from a; 

-- update nos dois registros do meio da tabela 
update a set nm = 'teste 2' where ctid = '(0,5)'; 
update a set nm = ' teste 2' where ctid = '(0,6)'; 

-- os valores presentes na páginas 0, index 5 e 6, foram para o fim, ocupando o 
index 11 e 12 
select ctid, nm from a; 

Com esse cenário testei as manutenções reindex, vacuum analyze, vacuum e vacuum 
full, nessa orderm, por fim, a única manutenção que reorganizou as páginas foi 
vacuum full. 
Pois bem, consultando a documentação do Postgres 9.0, está descrito que não 
deve-se utilizar de vacuum full, como forma de manutenção, deve-se realizar 
manutenções com vacuum (caso seja necessário) e/ou autovacuum. Resumindo, 
gostaria de entender melhor essa parte, porque essa tabela poderá ter muitos 
registros no futuro, e caso seja inserido muitos registros e atualiza alguns 
registros, terá páginas inteiras marcadas contendo "tuple dead", por fim, não 
fazendo o reaproveitamento das páginas, a tabela irá conter grandes quantidade 
de páginas utilizando muito espaço no Sistema Operacional, e fazendo com que a 
consulta sequencia faça varredura em todas páginas, como será controlado nessa 
situação? Somente com Fillfactor e Vacuum? Existe outros parâmetros de 
configuração para gerenciar esse cenário? 

Obrigado 

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