Le partitionnement dans postgresql fonctionne très bien pour les gros journaux. Créez d'abord la table parent :
create table game_history_log (
gameid integer,
views integer,
plays integer,
likes integer,
log_date date
);
Créez maintenant les partitions. Dans ce cas, une pour chaque mois, 900 000 lignes, serait bien :
create table game_history_log_201210 (
check (log_date between '2012-10-01' and '2012-10-31')
) inherits (game_history_log);
create table game_history_log_201211 (
check (log_date between '2012-11-01' and '2012-11-30')
) inherits (game_history_log);
Notez les contraintes de vérification dans chaque partition. Si vous essayez d'insérer dans la mauvaise partition :
insert into game_history_log_201210 (
gameid, views, plays, likes, log_date
) values (1, 2, 3, 4, '2012-09-30');
ERROR: new row for relation "game_history_log_201210" violates check constraint "game_history_log_201210_log_date_check"
DETAIL: Failing row contains (1, 2, 3, 4, 2012-09-30).
L'un des avantages du partitionnement est qu'il ne cherchera que dans la bonne partition, ce qui réduira considérablement et systématiquement la taille de la recherche, quel que soit le nombre d'années de données. Voici l'explication pour la recherche d'une certaine date :
explain
select *
from game_history_log
where log_date = date '2012-10-02';
QUERY PLAN
------------------------------------------------------------------------------------------------------
Result (cost=0.00..30.38 rows=9 width=20)
-> Append (cost=0.00..30.38 rows=9 width=20)
-> Seq Scan on game_history_log (cost=0.00..0.00 rows=1 width=20)
Filter: (log_date = '2012-10-02'::date)
-> Seq Scan on game_history_log_201210 game_history_log (cost=0.00..30.38 rows=8 width=20)
Filter: (log_date = '2012-10-02'::date)
Notez qu'en dehors de la table parent, il n'a analysé que la partition correcte. Évidemment vous pouvez avoir des index sur les partitions pour éviter un scan séquentiel.
