Creo que deberías usar un elements tabla:
-
Postgres podría usar estadísticas para predecir cuántas filas coincidirán antes de ejecutar la consulta, por lo que podría usar el mejor plan de consulta (es más importante si sus datos no están distribuidos uniformemente);
-
podrá localizar los datos de la consulta utilizando
CLUSTER elements USING elements_id_element_idx; -
cuando se publique Postgres 9.2, podrá aprovechar los escaneos de solo índice;
Pero he hecho algunas pruebas para 10 millones de elementos:
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
Entonces, por otro lado, las matrices son más pequeñas y tienen un índice más pequeño. Haría algunas pruebas de 200 millones de elementos antes de tomar una decisión.
