Je pense que vous devriez utiliser un elements tableau :
-
Postgres pourrait utiliser des statistiques pour prédire le nombre de lignes qui correspondront avant d'exécuter la requête, de sorte qu'il serait en mesure d'utiliser le meilleur plan de requête (c'est plus important si vos données ne sont pas uniformément réparties) ;
-
vous pourrez localiser les données de requête à l'aide des
CLUSTER elements USING elements_id_element_idx; -
lorsque Postgres 9.2 sera publié, vous pourrez profiter des analyses d'index uniquement ;
Mais j'ai fait quelques tests pour 10M d'éléments :
create table elements (id_item bigint, id_element bigint);
insert into elements
select (random()*524288)::int, (random()*32768)::int
from generate_series(1,10000000);
\timing
create index elements_id_item on elements(id_item);
Time: 15470,685 ms
create index elements_id_element on elements(id_element);
Time: 15121,090 ms
select relation, pg_size_pretty(pg_relation_size(relation))
from (
select unnest(array['elements','elements_id_item', 'elements_id_element'])
as relation
) as _;
relation | pg_size_pretty
---------------------+----------------
elements | 422 MB
elements_id_item | 214 MB
elements_id_element | 214 MB
create table arrays (id_item bigint, a_elements bigint[]);
insert into arrays select array_agg(id_element) from elements group by id_item;
create index arrays_a_elements_idx on arrays using gin (a_elements);
Time: 22102,700 ms
select relation, pg_size_pretty(pg_relation_size(relation))
from (
select unnest(array['arrays','arrays_a_elements_idx']) as relation
) as _;
relation | pg_size_pretty
-----------------------+----------------
arrays | 108 MB
arrays_a_elements_idx | 73 MB
Donc, d'un autre côté, les tableaux sont plus petits et ont un index plus petit. Je ferais des tests sur 200 millions d'éléments avant de prendre une décision.
