PostgreSQL Partition: Trabalhando com Partições no PostgreSQL

Neste artigo trabalharemos um ponto importante com rela��o ao SGBD PostgreSQL que � o particionamento, onde abordaremos sua conceitua��o, qual a necessidade de realizar esta tarefa e apresentaremos exemplos de sua cria��o, de forma a sanar d�vidas referentes a cria��o e utiliza��o de particionamento de tabelas.

Come�ando com as Parti��es

A primeira quest�o a ser levantada �: O que seria um particionamento? Particionamento, � na verdade o processo de dividir as tabelas em partes gerenci�veis menores, onde estas partes menores s�o chamadas de parti��es. O que ocorre no processo de particionamento � a divis�o da l�gica de uma grande tabela em m�ltiplas unidades f�sicas menores.

Dentre os motivos que nos levam a realizar o particionamento das tabelas, temos o que podemos considerar o mais importante que � para o aumento do desempenho da base de dados, o que � conseguido com o aux�lio dos Joins de parti��o, onde se precisarmos realizar uma s�rie de consultas numa tabela completa, a utiliza��o de parti��es nos ajudaria limitando o �mbito dessa pesquisa. A segunda raz�o mais importante � que com o particionamento das tabelas, torna-se muito mais f�cil o seu gerenciamento.

Outras vantagens que podemos ver s�o quando consultas ou atualiza��es acessam uma grande porcentagem de uma �nica parti��o, onde o desempenho pode ser melhorado, tendo como vantagem uma varredura sequencial da parti��o, ao inv�s de utilizar �ndices e acessos aleat�rios espalhados por toda a tabela. Opera��es de exclus�o podem ser realizadas pela adi��o ou mesmo remo��o de parti��es, onde as opera��es de ALTER TABLE NO INHERIT e DROP TABLE s�o ambas muito mais r�pido do que uma opera��o em massa. Al�m de que, com estes comandos temos a possibilidade de evitar a sobrecarga causada pelo VACUUM causado por uma exclus�o em massa de registros, dentre outras raz�es.

Hoje, na vers�o 9.4 do PostgreSQL, temos suporte ao particionamento atrav�s de heran�a entre tabelas, onde cada parti��o dever� ser criada como uma tabela filha de uma �nica tabela pai, a qual � vazia, existindo apenas para representar o conjunto de dados gerados. Para a implementa��o dos particionamentos no PostgreSQL, temos realiza-los de duas poss�veis formas, que s�o a Range partitioning e a List partitioning, as quais veremos a seguir uma breve descri��o.

Range partitioning (�intervalos de particionamento�)

Neste processo, temos que a tabela �mestra� � dividida em "intervalos", definidos por uma coluna chave ou por um conjunto de colunas, sem que haja uma sobreposi��o entre os intervalos dos valores atribu�dos a diferentes parti��es. Quando estamos trabalhando com intervalos de parti��o, podemos utilizar intervalos de datas ou registros num�ricos, por exemplo.

List partitioning (Lista de particionamentos)

Nesta forma, temos que a tabela � dividida em listas que de forma explicita, apresenta os valores chave de cada parti��o. Com rela��o a lista de particionamentos, podemos criar, por exemplo, listas de departamentos, como RH e financeiro.

Heran�a

Antes de darmos seguimento com as parti��es, precisamos entender primeiro o processo de implementa��o de heran�a que ocorre entre as tabelas do PostgreSQL, o que pode ser de grande utilidade ao criarmos nossas bases de dados. A heran�a � um conceito de bancos de dados orientados a objeto, que abre possibilidades interessantes para os projetos de bancos de dados, onde no PostgreSQL temos que uma tabela pode herdar de nenhuma ou de v�rias tabelas.

Para exemplificarmos a sua utiliza��o, vejamos a cria��o de um modelo de dados para cidades e estados, onde cada estado possui v�rias cidades, mas apenas uma capital para cada cidade. Para recuperarmos mais r�pido a capital, podemos criar duas tabelas para acelerar o processo, onde uma � para a capital e a outra para as cidades que n�o s�o capitais. Vejamos de acordo com as Listagens 1 e 2 como ficariam nossas tabelas.

Listagem 1. Cria��o da tabela empresa.

CREATE TABLE empresa(
       nome_empresa text,
       endereco text
      );

Listagem 2. Cria��o da tabela de departamentos.

CREATE TABLE departamento(
      nome_dep text,
      qtde_funcionarios int
      ) INHERITS (empresa);

Agora que temos as nossas tabelas criadas, adicionaremos alguns dados de teste para vermos o funcionamento, como mostra a Listagem 3.

Listagem 3. Inser��o de registros nas tabelas.

INSERT INTO empresa(nome_empresa, endereco) 
      VALUES('Empresa testes', 'Rua dos testes');
      INSERT INTO departamento(nome_empresa, endereco , nome_dep, qtde_funcionarios) 
      VALUES('Empresarial dos testes', 'Rua testador', 'Financeiro', 60);

Neste exemplo, temos que a tabela departamento herda todas as colunas da tabela pai, empresa, a qual possui duas colunas que s�o quantidade de funcion�rios e o nome do departamento.

Agora que entendemos um pouco sobre a heran�a, daremos continuidade a cria��o das parti��es, onde precisamos estar cientes de que existem ao todo, cinco passos necess�rios para a cria��o das parti��es no PostgreSQL, que s�o a cria��o da tabela principal (ou pai), cria��o das tabelas filhas, cria��o dos �ndices das tabelas, cria��o de triggers para a inser��o dos dados nas tabelas filhas e por �ltimo, habilitar a restri��o de exclus�o.

Intervalos de parti��o (Range Partitioning)

Quando utilizamos intervalos de parti��o, temos que este � o tipo de parti��o onde particionamos a tabela em intervalos menores, definidos por uma coluna �nica ou v�rias colunas. Ao definirmos os intervalos, precisamos tomar cuidado para que as tabelas estejam conectadas, n�o sobrepondo umas �s outras. Al�m disso, os intervalos devem ser definidos usando o operador (<). Para entendermos melhor com rela��o a parti��o de intervalos, criaremos agora um exemplo de sua utiliza��o, onde teremos os registros das vendas referentes ao ano de 2014.

Criando a tabela principal

Para come�armos o exemplo, criaremos inicialmente a nossa tabela principal, a qual chamaremos de registros_financeiros, teremos os campos apresentados de acordo com a Listagem 4. Nesta tabela, teremos todos os dados sobre as vendas armazenadas em uma base di�ria.

Listagem 4. Criando a tabela principal.

CREATE TABLE registros_financeiros
      (
      cod_registro NUMERIC PRIMARY KEY,
      qtde_vendas NUMERIC,
      data_venda DATE NOT NULL DEFAULT CURRENT_DATE
      );

Como apresentado pela Listagem 1, temos a nossa tabela principal, ou pai criada, onde todos os registros que forem inseridos ser�o movidos para as tabelas filhas com base nos crit�rios de data das vendas, o que ser� criado agora.

Criando uma tabela com intervalos de parti��o

Criada a tabela principal, implementaremos uma parti��o para a cria��o das tabelas filhas que herdar�o a tabela pai. Adicionaremos uma restri��o do tipo CHECK para as datas, o que ir� possibilitar que tenhamos os dados corretos para cada parti��o. Cada parti��o possuir� dados referentes a um trimestre, onde teremos as tabelas criadas de acordo com as Listagens 5, 6 e 7.

Listagem 5. Criando a tabela filho de janeiro a mar�o.

CREATE TABLE registros_financeiros_jan_mar
      (
      PRIMARY KEY (cod_registro, data_venda),
      CHECK (data_venda >= DATE '2015-01-01' AND data_venda < DATE '2015-04-01')
      )
      INHERITS (registros_financeiros);

Listagem 6. Criando a tabela filha dos meses abril a junho.

CREATE TABLE registros_financeiros_abril_junho
      (
      PRIMARY KEY (cod_registro, data_venda),
      CHECK (data_venda >= DATE '2015-04-01' AND data_venda < DATE '2015-07-01')
      )
      INHERITS (registros_financeiros);

Listagem 7. Criando a tabela dos registros de julho a setembro.

CREATE TABLE registros_financeiros_jul_set
      (
      PRIMARY KEY (cod_registro, data_venda),
      CHECK (data_venda >= DATE '2015-07-01'
      AND data_venda < DATE '2015-10-01')
      )
      INHERITS (registros_financeiros);

Criando �ndices para as tabelas

Agora que temos nossas tabelas criadas, iremos adicionar �ndices para cada uma das tabelas filhas para que dessa forma possamos agilizar ainda mais as consultas. Os �ndices ser�o criados no campo data_venda e servir� para qualquer opera��o DML (INSERT, SELECT ou UPDATE) referente ao campo de data. Os �ndices ser�o criados de acordo com as instru��es a seguir:

CREATE INDEX data_venda_jan_mar_idx ON registros_financeiros_jan_mar (data_venda);
      CREATE INDEX data_venda_abril_junho_idx ON registros_financeiros_abril_junho (data_venda);
      CREATE INDEX data_venda_jul_set_idx ON registros_financeiros_jul_set (data_venda);

Utiliza��o de triggers

Ap�s a realiza��o das tabelas e dos �ndices, o pr�ximo passo � a cria��o da trigger que ser� disparada pela tabela principal, onde as condi��es devem ser as mesmas aplicadas nas tabelas filhas. Vejamos ent�o de acordo com a Listagem 8 como ficar� a nossa trigger.

Listagem 8. Desenvolvendo a trigger para a tabela principal.

CREATE OR REPLACE FUNCTION insercao_registros()
      RETURNS TRIGGER AS $
      BEGIN
      IF (NEW.data_venda >= DATE '2015-01-01' AND
      NEW.data_venda < DATE '2015-04-01') THEN
      INSERT INTO registros_financeiros_jan_mar VALUES (NEW.*);
      ELSEIF (NEW.data_venda >= DATE '2015-04-01' AND
      NEW.data_venda < DATE '2015-06-01') THEN
      INSERT INTO registros_financeiros_abril_junho VALUES (NEW.*);
      ELSEIF (NEW.data_venda >= DATE '2015-06-01' AND
      NEW.data_venda < DATE '2015-09-01') THEN
      INSERT INTO registros_financeiros_jul_set VALUES (NEW.*);
      ELSE
      RAISE EXCEPTION 'A data n�o se encontra nos limites estabelecidos para a inser��o...';
      END IF;
      RETURN NULL;
      END;
      $ LANGUAGE plpgsql;

O �nico prop�sito desta fun��o que acabamos de criar � para que os dados sejam preenchidos nas respectivas tabelas com base na data dos registros financeiros da empresa. Para que a trigger criada na Listagem 8 seja disparada, precisaremos de uma fun��o que ir� executar a trigger no momento em que as instru��es de INSERT, UPDATE e DELETE forem disparadas. Esta trigger function, que chamaremos de registro_mes_trigger, ser� definida de acordo com a apresentada pela Listagem 9.

Listagem 9. Criando a trigger function.

CREATE TRIGGER registro_mes_trigger
      BEFORE INSERT ON registros_financeiros
      FOR EACH ROW
      EXECUTE PROCEDURE insercao_registros();

Trabalhando com as constraints exclusions

Como �ltima etapa a ser realizada, temos a implementa��o das restri��es de exclus�o, ou constraints exclusion, onde esta � uma t�cnica voltada para a otimiza��o das consultas que buscam melhoria de desempenho para as tabelas particionadas que foram definidas no decorrer do artigo. Para que possamos definir a restri��o como ativa, o processo � realizado da seguinte forma:

SET constraint_exclusion = on;
      SELECT count(*) FROM registros_financeiros WHERE data_venda >= DATE '2015-03-01';

Caso a constraint_exclusion n�o tenha sido definida, a consulta ser� realizada em cada uma das parti��es da tabela de registros_financeiros. No entanto, quando a restri��o � habilitada, as constraints de cada parti��o ser�o examinadas, onde ser� verificada a necessidade de pesquisa apenas nas tabelas que estejam de acordo com a cl�usula WHERE da consulta.

Parti��es e opera��es DML

No momento em que executamos uma instru��o de INSERT na tabela principal, temos que a trigger insercao_registros(), criada anteriormente ser� acionada e em sequ�ncia, chamar� a trigger function registro_mes_trigger, onde com base no campo data_venda teremos os dados salvos na tabela filha espec�fica. Para vermos o funcionamento da nossa estrutura, iremos inserir alguns registros na tabela registros_financeiros, para que em seguida, utilizemos o comando SELECT para ver o resultado final da opera��o. Vejamos ent�o de acordo com a Listagem 10.

Listagem 10. Inser��o de registros na tabela principal, registros_financeiros.

INSERT INTO registros_financeiros (cod_registro, qtde_vendas, data_venda) VALUES (1, 300, TO_DATE('05/03/2015','MM/DD/YYYY'));
      INSERT INTO registros_financeiros (cod_registro, qtde_vendas, data_venda) VALUES (2, 700, TO_DATE('07/15/2015','MM/DD/YYYY'));
      INSERT INTO registros_financeiros (cod_registro, qtde_vendas, data_venda) VALUES (3, 450, TO_DATE('02/08/2015','MM/DD/YYYY'));
      INSERT INTO registros_financeiros (cod_registro, qtde_vendas, data_venda) VALUES (5, 1300, TO_DATE('05/15/2015','MM/DD/YYYY'));
      INSERT INTO registros_financeiros (cod_registro, qtde_vendas, data_venda) VALUES (6, 900, TO_DATE('02/27/2015','MM/DD/YYYY'));
      INSERT INTO registros_financeiros (cod_registro, qtde_vendas, data_venda) VALUES (7, 3000, TO_DATE('08/07/2015','MM/DD/YYYY'));
      INSERT INTO registros_financeiros (cod_registro, qtde_vendas, data_venda) VALUES (8, 1500, TO_DATE('08/17/2015','MM/DD/YYYY'));
      INSERT INTO registros_financeiros (cod_registro, qtde_vendas, data_venda) VALUES (9, 1000, TO_DATE('01/27/2015','MM/DD/YYYY'));
      INSERT INTO registros_financeiros (cod_registro, qtde_vendas, data_venda) VALUES (10, 4000, TO_DATE('07/06/2015','MM/DD/YYYY'));
      INSERT INTO registros_financeiros (cod_registro, qtde_vendas, data_venda) VALUES (11, 3000, TO_DATE('04/20/2015','MM/DD/YYYY'));

Com nossos registros inseridos, realizaremos inicialmente uma consulta na tabela principal para que possamos ver o resultado que nos ser� apresentado, e em seguida, realizaremos uma consulta em uma das tabelas filhas para verificarmos os registros que foram inseridos. Realizaremos nossas consultas de acordo com as instru��es a seguir, seguidas dos resultados apresentados pelas Figuras 1 e 2.

SELECT * FROM registros_financeiros;

Figura 1. Consultando a tabela registros_financeiros.

SELECT * FROM registros_financeiros_abril_junho;

Figura 2. Consulta na tabela filha.

Como podemos observar na tabela filha, referente as vendas dos meses de abril a junho, temos apresentados tr�s registros inseridos, sendo que dois foram no m�s de maio e um de abril. Com rela��o as instru��es de UPDATE ou DELETE, n�o precisaremos criar nenhuma nova trigger, pois a trigger de inser��o criada anteriormente resolve o nosso problema. Para demonstrarmos isso, realizaremos inicialmente a atualiza��o em um dos registros e verificaremos o impacto realizado sobre a tabela filha, como podemos ver de acordo com a instru��o a seguir:

UPDATE registros_financeiros SET data_venda = TO_DATE('03/10/2015','MM/DD/YYYY') WHERE cod_registro = 9;

O resultado apresentado ao realizarmos uma consulta sobre a tabela filha de janeiro a mar�o ser� ent�o apresentado com um novo registro, como mostra a Figura 3, com base na instru��o de pesquisa a seguir:

SELECT * FROM registros_financeiros_jan_mar;

Figura 3. Atualiza��o da tabela filha registros_financeiros_jan_mar.

Por fim, realizaremos agora a exclus�o de um dos registros, o qual se aplica da seguinte forma:

DELETE FROM registros_financeiros WHERE data_venda = TO_DATE('03/10/2015','MM/DD/YYYY');

List partitioning (Lista de particionamentos)

Ao tratarmos de lista de parti��es, temos que esta � uma maneira similar ao Range partitioning, com a diferen�a de que a tabela � dividida listando-se explicitamente os valores-chave que aparecem em cada parti��o. Neste caso, cada parti��o � definida e designada com base em um valor de coluna presente em um conjunto de listas de valores, ao contr�rio de ser com base em um conjunto de faixas de valores adjacentes, o qual ser� realizado atrav�s da defini��o de cada parti��o por meio dos valores representados pelo value_list, onde value_list � uma lista de valores separados por v�rgulas.

Para nosso prop�sito, criaremos novas tabelas principal e filhas, as quais conter�o os registros financeiros da empresa de vendas em conjunto com as informa��es das cidades que possuem uma unidade da empresa em quest�o. Neste caso, teremos a coluna cidade como sendo a base para a cria��o da nossa lista de parti��es. Dito isso, criaremos inicialmente a nossa tabela principal, a qual chamaremos de registros_financeiros_listaParticao, como mostra a Listagem 11.

Listagem 11. Cria��o da tabela principal.

CREATE TABLE registros_financeiros_listaParticao
      (
      cod_reg NUMERIC primary key,
      data_venda date,
      qtd_vendas NUMERIC,
      cidade_empresa text
      );

Agora, ser�o criadas as tabelas filhas, como podemos ver de acordo com as instru��es apresentadas pelas Listagens 12 e 13.

Listagem 12. Cria��o da tabela filha registros_financeiros_1.

CREATE TABLE registros_financeiros_1
      (
      PRIMARY KEY (cod_reg, didade_empresa),
      CHECK (didade_empresa IN ('Recife', 'Caruaru'))
      )
      INHERITS (registros_financeiros_listaParticao);
      Listagem 13. Cria��o da tabela filha registros_financeiros_2.
       CREATE TABLE registros_financeiros_2
      (
      PRIMARY KEY (cod_reg, didade_empresa),
      CHECK (didade_empresa IN ('Vit�ria', 'Fortaleza'))
      )
      INHERITS (registros_financeiros_listaParticao);
      Realizada a cria��o das tabelas, ser�o criados os �ndices para as tabelas geradas, os quais geraremos de acordo com as seguintes instru��es:
      CREATE INDEX listaParticao1_idx ON registros_financeiros_1(didade_empresa);
      CREATE INDEX listaParticao2_idx ON registros_financeiros_2(didade_empresa);

Em seguida, criaremos as triggers principal e a trigger function para realizarmos a atualiza��o das tabelas, como mostra as Listagens 14 e 15.

Listagem 14. Cria��o da trigger function.

CREATE OR REPLACE FUNCTION insere_registros_listaParticao()
      RETURNS TRIGGER AS $
      BEGIN
      IF (NEW.didade_empresa IN ('Recife', 'Caruaru')) THEN
      INSERT INTO registros_financeiros_1 VALUES (NEW.*);
      ELSEIF (NEW.didade_empresa IN ('Vit�ria', 'Fortaleza')) THEN
      INSERT INTO registros_financeiros_2 VALUES (NEW.*);
      ELSE
      RAISE EXCEPTION 'A cidade n�o foi encontrada na listagem especificada...';
      END IF;
      RETURN NULL;
      END;
      $ LANGUAGE plpgsql;

Listagem 15. Cria��o da trigger auxiliar registros_financ_trigger.

CREATE TRIGGER registros_financ_trigger
      BEFORE INSERT ON registros_financeiros_listaParticao
      FOR EACH ROW
      EXECUTE PROCEDURE insere_registros_listaParticao();

Para finalizarmos, realizaremos a inser��o de alguns registros para vermos o funcionamento das instru��es, como mostra a Listagem 16.

Listagem 16. Inser��o de registros na tabela principal.

INSERT INTO registros_financeiros_listaparticao(cod_reg, data_venda, qtd_vendas, didade_empresa) VALUES (1, '16-07-2015', 1500, 'Vit�ria');
      INSERT INTO registros_financeiros_listaparticao(cod_reg, data_venda, qtd_vendas, didade_empresa) VALUES (2, '26-03-2015', 3500, 'Fortaleza');
      INSERT INTO registros_financeiros_listaparticao(cod_reg, data_venda, qtd_vendas, didade_empresa) VALUES (3, '10-09-2015', 500, 'Caruaru');
      INSERT INTO registros_financeiros_listaparticao(cod_reg, data_venda, qtd_vendas, didade_empresa) VALUES (4, '16-12-2015', 1500, 'Recife');
      INSERT INTO registros_financeiros_listaparticao(cod_reg, data_venda, qtd_vendas, didade_empresa) VALUES (5, '18-10-2015', 5000, 'Fortaleza');

Com os registros inseridos, vejamos atrav�s da instru��o SELECT como ser�o apresentadas as informa��es em uma das tabelas filhas, como mostrado a seguir:

select * from registros_financeiros_2;

Com base na instru��o de sele��o, tivemos os dados apresentados como mostra a Figura 4, onde temos que 3 registros foram inseridos, sendo que dois foram para Fortaleza.

Figura 4. Visualiza��o dos resultados da tabela filha.

Com isso finalizamos este artigo, no qual foram apresentadas as t�cnicas de particionamento de tabelas para a base de dados PostgreSQL, onde para isso, precisamos entender conceitos de heran�a entre as tabelas para que pud�ssemos capitar melhor o motivo de tal necessidade. Esperamos que tenham gostado. At� a pr�xima! =)

Links

DLL Inherit
http://www.postgresql.org/docs/9.4/static/ddl-inherit.html

DLL Partitioning
http://www.postgresql.org/docs/9.4/static/ddl-partitioning.html

Confira outros conte�dos:

SQL SUM: somando os valores de uma...

SQL: INNER JOIN

SQL: Introdu��o ao Where

Assista grátis a nossa aula inaugural

Perguntas frequentes

Quem somos?

Por que a programação se tornou a profissão mais promissora da atualidade?

Como faço para começar a estudar?

Em quanto tempo de estudo vou me tornar um programador?

Sim, você pode se tornar um programador e não precisa ter diploma de curso superior!

O que eu irei aprender estudando pela DevMedia?

Principais diferenciais da DevMedia

Qual o investimento financeiro que preciso fazer para me tornar um programador?

Como funciona a forma de pagamento da DevMedia?

Por Edson Em 2016

Nossos casos de sucesso

Leonardo Carlos

Eu sabia pouqu�ssimas coisas de programa��o antes de come�ar a estudar com voc�s, fui me especializando em v�rias �reas e ferramentas que tinham na plataforma, e com essa bagagem consegui um est�gio logo no in�cio do meu primeiro per�odo na faculdade.

Lucas Rodrigues

Estudo aqui na Dev desde o meio do ano passado! Nesse per�odo a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta � continuar estudando e praticando para ser um Full-Stack Dev!

Her�clito J�nior

Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma � bem intuitiva e muuuuito did�tica a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!

Julio Cablen

Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda n�o tinha visto. A did�tica � do jeito que qualquer pessoa consegue aprender. S�rio, to apaixonado, adorando demais.

Joelberth Sena

Adquiri o curso de voc�s e logo percebi que s�o os melhores do Brasil. � um passo a passo incr�vel. S� n�o aprende quem n�o quer. Foi o melhor investimento da minha vida!

Felipe Nunes

Foi um dos melhores investimentos que j� fiz na vida e tenho aprendido bastante com a plataforma. Voc�s est�o fazendo parte da minha jornada nesse mundo da programa��o, irei assinar meu contrato como programador gra�as a plataforma.

Wanderson Oliveira

Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exerc�cios pr�ticos que n�o tem como n�o aprender, est�o de parab�ns!

Jos� Lucas

Obrigado DevMedia, nunca presenciei uma plataforma de ensino t�o presente na vida acad�mica de seus alunos, parab�ns!

Eduardo Dorneles

Aprendi React na plataforma da DevMedia h� cerca de 1 ano e meio... Hoje estou h� 1 ano empregado trabalhando 100% com React!

Adauto Junior

J� fiz alguns cursos na �rea e nenhum � t�o bom quanto o de voc�s. Estou aprendendo muito, muito obrigado por existirem. Est�o de parab�ns... Espero um dia conseguir um emprego na �rea.

Ver todos os casos de sucesso

PostgreSQL Partition: Trabalhando com Parti��es no PostgreSQL

Neste artigo veremos como lidar com o particionamento das tabelas no PostgreSQL, o que se torna uma boa pr�tica no momento em que precisamos realizar pesquisas r�pidas.

Come�ando com as Parti��es

Range partitioning (�intervalos de particionamento�)

List partitioning (Lista de particionamentos)

Heran�a

Intervalos de parti��o (Range Partitioning)

Criando a tabela principal

Criando uma tabela com intervalos de parti��o

Criando �ndices para as tabelas

Utiliza��o de triggers

Trabalhando com as constraints exclusions

Parti��es e opera��es DML

List partitioning (Lista de particionamentos)

Confira outros conte�dos:

SQL SUM: somando os valores de uma...

SQL: INNER JOIN

SQL: Introdu��o ao Where

Perguntas frequentes

Nossos casos de sucesso