Postgresql - wydajność korzystania z tablicy w dużej bazie danych

Myślę, że powinieneś użyć elements tabela:

• Postgres byłby w stanie użyć statystyk do przewidzenia, ile wierszy będzie pasować przed wykonaniem zapytania, dzięki czemu będzie mógł użyć najlepszego planu zapytań (jest to ważniejsze, jeśli dane nie są równomiernie rozłożone);

• będziesz w stanie zlokalizować dane zapytania za pomocą CLUSTER elements USING elements_id_element_idx;

• kiedy Postgres 9.2 zostanie wydany, będziesz mógł skorzystać ze skanowania tylko indeksu;

Ale wykonałem kilka testów dla elementów 10M:

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

Z drugiej strony tablice są mniejsze i mają mniejszy indeks. Przed podjęciem decyzji wykonałbym kilka testów elementów 200M.