PostgreSQL的 - 在大数据库中使用阵列的性能(Postgresql - performan

让我们说我们有600万条记录的表。有16整数列和几个文本列。它是只读的表，每一个整数列有一个索引。每一个纪录是50-60字节。

该表的名称是“项目”
服务器是：12 GB RAM，1,5- TB SATA，4个核。所有服务器的Postgres。
有很多在这个数据库中，因此RAM并不包括所有的数据库多个表。

我想添加到餐桌“物品”一栏“a_elements”（数组类型大整数），每条记录将在此列不超过50-60元。

从那以后，我将创建此列，典型的查询应该是这样的指标GIN：

select * from item where ...... and '{5}' <@ a_elements;

我也有第二个，更经典，选项。

别列a_elements两列添加到表项目，但创建表的元素：

id_item
id_element

此表将有大约200万的记录。

我能够做这个表分区等等的记录数将减少到20万表元素和500 K的表项。

第二个选项查询看起来是这样的：

select item.* 
from item 
    left join elements on (item.id_item=elements.id_item) 
where .... 
and 5 = elements.id_element

我不知道什么选择是在性能上来看比较好。 Postgres的是能够在一个单一的查询中使用索引GIN（选项1）许多不同的指标？

我需要做出一个很好的决定，因为这个数据的导入将带我20天。

我认为你应该使用的elements表：

Postgres的将能够使用统计数据来预测有多少行会在执行查询之前匹配，所以它能够用最好的查询计划（更重要的是，如果你的数据不是均匀分布的）;
你就可以使用本地化查询数据CLUSTER elements USING elements_id_element_idx ;
当Postgres的9.2会被释放，那么你将能够采取的唯一索引扫描的优势;

但是我做了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

因此，在另一方面阵列较小，并有小的索引。我在做决定之前做一些200M元素测试。