考虑以下表格
Table "public.Foo"
Column | Type |
------------------+-----------------------------+
foo_id | integer | PK
bar_id | integer | FK to bars
....
Table "public.Bar"
Column | Type |
------------------+-----------------------------+
bar_id | integer | PK
....
Table "public.very_big"
Column | Type |
------------------+-----------------------------+
foo_id | integer
....
Bar被映射到Foo，因此Bar有很多Foos。有＆lt; 50条，每条都有数百个Foos。然后，我有一个非常大的单独的表，＆gt; 2亿行，引用Foos（以及其他表格），创建一个大的复合主键，导致表格大小。
在理想的世界中，我想在bar_id上对very_big进行分区，而不必为bar_id添加列，只需使用foo_id的引用即可。这将提供大量的分区，1-50个数量级，而直接在foo_id上进行分区将是数千个，这在documentation中被建议。
从某种意义上说，这个理想世界是基于连接的列表分区。根据文档，我觉得这是不可能的。它还提出了一些毛茸茸的问题，比如如果改变foo-bar关系使得数据必须移动分区，那么一个分区中的数据会发生什么？因此，这似乎不可能/没有意义。
一种替代方法是使用手动定义的列表分区。这将导致每个手动定义的范围具有大约300-500个值。这种方法的一些缺点是1）如果参考在foo和bar之间发生变化，如上所述，分区完全毁了（我不预见到这种情况发生，否则我不会考虑这个解决方案，但它＆＃39 ; s仍然是一个缺点）2）300-500值的大型非连续列表分区定义对于postgres查询规划器来说性能较差。 3）新添加的Foos基于预定义的列表无法获得，因为它们不会被添加到分区定义中。
另一种方法是将其吸取并将bar_id的列添加到very_big，但这是非正常且冗余的。
＆＃34;加入＆＃34;基于列表分区可能？ （我想不是）
如果没有，是否存在非连续，100个数量级的基于列表的分区的性能影响？ （不确定，但这里还有其他费用）
我可能缺少这个问题的其他解决方案吗？我计划选择＆＃34;非规范化＆＃34;暂时解决方案并将bar_id添加到very_big并基于该
定义分区谢谢